Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Zelenac 02. 02. 2016, 14:07:07
-
Zdravím,
zajímalo by mně, jak by zdejší Java guru vyřešili tohle:
Dělám si client-server komunikační aplikaci, kterážto se později vyvine do P2P. To vyžaduje knihovnu, která obstarává naslouchání na portu (SocketServer) a dále obsluhu vzniklých Socketů (keepAlive, odesílání práv, příjem zpráv, rušení připojení, info o délce neaktivity socketů, atd.). Dále je třeba vytvořit další zaobalení těchto tříd a vytvořit třídu která v sobě sdružuje další funkcionality: typ odeslané zprávy (číže protokoly pro: chat, soubor, signalizace). A vzniknout další a další.
Je zřejmé, že takováto věc vyžaduje spoustu událostí, píše-li se správně objektově a to je prostě v Javě boží utrpení. Pořád dokolečka psát: listener kolekce, metody pro vyvolání událostí, foreache, interfacy. Obzvláště ty interfacy jsou velká lahůdka: co když třída má 20 událostí a já chci v jiné třídě reagovat pouze na 1? To musím buďto:
1. Napsat jednotný IListener interface kde budou všechny události k dané třídě. To vede k tomu, že pakliže v nějaké jiné třídě potřebuji jen události 2, stejně se mi jich tam bouchne dalších 18 které tam budou v souboru nevyužité strašit.
2. Napsat pro každou jednu událost jeden interface. No tak to tedy hodně štěstí při vývoji takovéto architektury, protože každý interface musí být v samostatném souboru, což je obrovská halda úkonů, která je k tomu nutná.
Prostě takové aplikace je plná událostí, nejde to elegantně řešit nijak jinak. Co s takovýmto hrozivým jazykem?
PS: Píšu to v Javě ze studijích důvodů, jinak bych to napsal hned v Qt.
-
Trebas ve swingu se casto objevuje pattern, ze mas interface FooListener s dvaceti metodami a pro snazsi pouziti existuje abstraktni trida AbstractFooListener, kde maji vsechny ty metody defaultni (typicky prazdnou) implementaci. Pak dedis z AbstractFooListener. Kod uvnitr frameworku temer vsechno typuje na interface (FooListener).
-
Tvuj problem jsem prilis nepochopil, ale pouze strucne k jave, kterou jsi mozna jeste uplne neovladl. Neni pravda, ze kazdy intefarce musi byt v samostatnem souboru (BTW proc by to melo vadit?). Pokud je caste, ze se implementuje pouze cast interface, lze pouzit default implementace v interface nebo treba skeletalni implementace, coz umoznuje vice castecnych specializaci.
-
Za prvé bych doporučil nevynalézat kolo a použít na to komunikaci hotovou knihovnu – doporučuju Netty (http://netty.io/). Dále píšete o správném objektovém programování, to nejde dohromady s tím, že třída reaguje na 20 událostí. Ve správném objektovém programování má třída jednu zodpovědnost, bude tudíž mít jen pár metod nebo reagovat jen na pár událostí.
Co s takovýmto hrozivým programátorem?
Buď se to programátor naučí, nebo bude lepší, když bude dělat něco jiného.
-
Nebudu řešit širší souvislosti, protože to by bylo na dlouho… tak jen stručně k těm implementačním detailům.
Když se ti nelíbí rozhraní/třída s mnoha metodami, máš i další možnosti:
a) Rozhraní bude mít hodně metod, ale uděláš k němu i výchozí implementaci (abstraktní třídu), která implementuje všechny metody, ale bude je mít prázdné. Ve své implementaci podědíš tuto abstraktní a překryješ jen metody (události), které tě zajímají.
b) Využiješ vhodně dědičnost nebo kompozici – rozhraní bude mít jednu nebo několik málo metod typu processEvent(Event e), přes kterou půjde všechny typy událostí, a implementace si z těch (komponovaných nebo poděděných objektů) vybere to, co ji zajímá.
c) Rozděl si události do logických skupin a pro ně vytvoř rozhraní listenerů – jednak je to vhodnější návrh a jako pozitivní vedlejší efekt tam nebudeš mít tolik metod. Tenhle přístup můžeš zároveň kombinovat s a)
Pro nízkoúrovňové věci (implementaci síťového protokolu) ti dobře poslouží Netty, jak píše Filip.
-
Správně je odpověď č. 2. Vytvoření dvaceti rozhraní nevidím jako nějaký problém. Těch rozhraní však nemusí být 20, ale tolik, kolik je jich potřebných (některé události bývají vždy obsluhovány ve skupině). Výhodou takových rozhraní je, že se často dají používat napříč celou aplikací, tedy nejen určitou skupinou tříd z jednoho balíku.
O tom v podstatě hovoří Interface Segregation Principle ze SOLID.
Jak však již bylo uvedeno, obsluhovat 20 událostí v jedné třídě je přinejmenším podivné a těžko slučitelné s objektovým programováním - ukazuje to na závažné porušení Single Responsibility Principle, opět ze SOLID.
-
mozes si rozdne pomoct. java neni c++ a da sa vselico robit "za behu". mrkni napr na google eventbus
-
Za prvé bych doporučil nevynalézat kolo a použít na to komunikaci hotovou knihovnu – doporučuju Netty (http://netty.io/). Dále píšete o správném objektovém programování, to nejde dohromady s tím, že třída reaguje na 20 událostí. Ve správném objektovém programování má třída jednu zodpovědnost, bude tudíž mít jen pár metod nebo reagovat jen na pár událostí.
Co s takovýmto hrozivým programátorem?
Buď se to programátor naučí, nebo bude lepší, když bude dělat něco jiného.
1. Ad Nevynálezat kolo - to v IT solo znamená nedělat vůbec nic, neb vše možné pro jednince proveditelné už existuje a ještě v několika variantách. Navíc píšu to, jak si můžete ráčit všimnou, ze studijních důvodů - jinak bych se neštval s Javou.
2. Ad Třída nemá mít 20 událostí a pokud ano, je něco blbě. Jsem lenivý a tak si značně ulehčím odpověď na tento žvást: Každé přinejmenším GUI je miriáda událostí.
Kukacka:
public interface musí být v samostatném souboru, vždy po jednom - alespoň dle Eclipse. Private interface by mi byl v mé situaci jaksi k ničemu.
Zatím nejlepší řešení je dle mého názoru použít tu abstraktní třídu, jak zmiňuje Turban Legend a Ondrej Satai Nekola. Tou mi ale odpoadne pouze nepříjemnost s interfacováním, zůstává mi pořád ještě:
1. Dokolečka psát addListener, removeListener, ArrayList<Listener> listeners, foreache, instrafacy a teď ještě i abstraktní třídy.
2. Ve třídách reagujících na událost tyto interfacy/abstraktní třídy následně implementovat.
3. S množstvím event přibývá chaos ten, že nevím, jaký inteface/abstraktClass patří ke které třídě, aniž bych použil funkci hledat a zjistil si to ručně. (v C# nebo v Qt stačí mrknout k eventě/signálu v našeptávači a napíše mi to popis eventy, stejně jako je to u popisů metod - je to kompfortní, je to rychlejší. V javě tato funkcionalita jaksi zcela odpadá.)
-
dela se to pomoci aspektoveho programovani. Pokud pouzijes treba google eventbus (jak pise andy), tak nad metodu das @Subscribe a ta bude prijimat jen event ktery potrebujes.
-
2. Ad Třída nemá mít 20 událostí a pokud ano, je něco blbě. Jsem lenivý a tak si značně ulehčím odpověď na tento žvást: Každé přinejmenším GUI je miriáda událostí.
Reagujes na neco jineho. V systemu muze byt udalosti docela dost, ale nemusis mit (pri slusnem navrhu) vsechno na jedne hromade v jedne tride.
Kukacka:
public interface musí být v samostatném souboru, vždy po jednom - alespoň dle Eclipse. Private interface by mi byl v mé situaci jaksi k ničemu.
Ja bych to nedelal, ale pokud chces workaround, tak staticke verejne interfacy uvnitr tridy, ktera ti slouzi jenom jako namespace. Ale ve skutecnosti to asi nechces a chces mit samostatne soubory (ostatne proc ne?)
1. Dokolečka psát addListener, removeListener, ArrayList<Listener> listeners, foreache, instrafacy a teď ještě i abstraktní třídy.
Vidim tam prostor pro refaktoring spolecne funkcionality? Interfacy musis psat tak jako tak. A abstraktni tridy ti udela zadarmo IntelliJ.
2. Ve třídách reagujících na událost tyto interfacy/abstraktní třídy následně implementovat.
Ten kod preci potrebujes tak jako tak.
3. S množstvím event přibývá chaos ten, že nevím, jaký inteface/abstraktClass patří ke které třídě, aniž bych použil funkci hledat a zjistil si to ručně. (v C# nebo v Qt stačí mrknout k eventě/signálu v našeptávači a napíše mi to popis eventy, stejně jako je to u popisů metod - je to kompfortní, je to rychlejší. V javě tato funkcionalita jaksi zcela odpadá.)
Pouzivas nejake slusne IDE? (cimz myslim IntelliJ, pochopitelne)
-
Navíc píšu to, jak si můžete ráčit všimnou, ze studijních důvodů - jinak bych se neštval s Javou.
Pokud to píšete ze studijních důvodů, doporučoval bych naučit se v Javě programovat a naučit se používat IDE. Zatím to vypadá, že studujete to, zda se v Javě dá programovat, i když to neumíte a umět nechcete – ano, dá, a jako v kterémkoli jiném jazyce, výsledek bude stát za … vy víte co.
-
zda se v Javě dá programovat, i když to neumíte a umět nechcete – ano, dá, a jako v kterémkoli jiném jazyce, výsledek bude stát za … vy víte co.
A oproti jiným jazykům to má navíc tu výhodu, že to bude pomalé a neskutečně rozežrané. ;D 8)
-
1. Dokolečka psát addListener, removeListener, ArrayList<Listener> listeners, foreache, instrafacy a teď ještě i abstraktní třídy.
2. Ve třídách reagujících na událost tyto interfacy/abstraktní třídy následně implementovat.
3. S množstvím event přibývá chaos ten, že nevím, jaký inteface/abstraktClass patří ke které třídě, aniž bych použil funkci hledat a zjistil si to ručně. (v C# nebo v Qt stačí mrknout k eventě/signálu v našeptávači a napíše mi to popis eventy, stejně jako je to u popisů metod - je to kompfortní, je to rychlejší. V javě tato funkcionalita jaksi zcela odpadá.)
1. Proc? Tak snad budes mit jednu trida, ktera prijme vsechny eventy a nasledne je rozhazi vsem, kteri se do ni zaregistruji. A pokud je struktura listeneru staticka, tak ani nemusis mit addListener, ale proste ty hlavni tride posles vsechny potencialni listenery.
2. No tak pokud chces reagovat na nejakou event, tak vetsinou musis implementovat tu metodu, co to udela.:D
3. WTF? Co si predstavujes pod pojmem "popis eventy"? Event je proste POJO. Jestli to ma mit link na to, kdo ji vyhodil, musis si tam ten link dodat.
Podle tveho popisu, to co ma Qt je nejaky druh UI eventy, ktera uz je specializovana. Samozrejme to, co potrebuje UI event nepotrebuji nejaky udalosti mezi servery na backendu, takze je blbost pouzivat UI event.
Zacinam mit pocit, ze jsi bud nejakej Troll nebo mas vazne nedostatky ve znalostech a svadis to na jazyk.
-
A oproti jiným jazykům to má navíc tu výhodu, že to bude pomalé a neskutečně rozežrané. ;D 8)
Tak jsem se spletl. Troll je nekdo jinej...
-
zda se v Javě dá programovat, i když to neumíte a umět nechcete – ano, dá, a jako v kterémkoli jiném jazyce, výsledek bude stát za … vy víte co.
A oproti jiným jazykům to má navíc tu výhodu, že to bude pomalé a neskutečně rozežrané. ;D 8)
Bullshit.
-
2. Ad Třída nemá mít 20 událostí a pokud ano, je něco blbě. Jsem lenivý a tak si značně ulehčím odpověď na tento žvást: Každé přinejmenším GUI je miriáda událostí.
Není přece nutné všech 20 událostí obsluhovat v jedné obludné třídě. Ta třída si prostě zaslouží rozdělení do více menších tříd dle kompetencí.
-
si pozrite ako su eventy v swingu
mate objekt Event, ten nesie timestamp, kto ho odoslal. mate napr. mouseclick event, ktory nesie x y koordinaty, tlacidlo mysi atd
mate listener MouseListener s piatimi metodami (kliklo sa, stlacilo sa stlacidlo, pustilo sa, +2x fokus)
mate MouseAdapter ktory prekryje vsetky metody prazdnym spravanim takze nemusite potom implementovat 5 metod ale len tu ktoru vam treba
---
alternativne: publikujete do generickeho busu konkretne objekty typu event (pripojil sa klient event, odpojil sa klient event)
mate genericky interfejs void handle(Event) ktory sa rozhodne ci to obsluzi alebo nie
alternativne: java ee / spring styl: publikujete do generickeho busu lubovolne objekty, anotujete metodu ako posluchaca na event daneho typu, reflexiou zistite ci anotovana metoda posluchaca vie zozrat dany objekt, ak ano, zavolate ju dynamicky
-
. No tak to tedy hodně štěstí při vývoji takovéto architektury, protože každý interface musí být v samostatném souboru, což je obrovská halda úkonů, která je k tomu nutná.
obrovska halda ukonov? to buildujete z terminalu cez javac? za normalnych okolnosti je to File | New | Interface
-
Toto je taky ten klasicky problem - snaha aplikovat zlozvyky z ineho jazyka do druheho. Klasicky C++ pristup robit vsetko rucne, alebo mat cely program v jednom subore sa v jave velmi nenosi (nastastie). V eclipse je ta halda ukonov par klavesovych skratiek. Ale hlavne nie je nutne davat to do samotnych suborov. Co sa tyka nejakej absencie na eventy - .net bezi uz aj na linuxe, v c# mate delegatov, tak sa nemusite trapit s javou ked vas neoslovila...
-
Toto je taky ten klasicky problem - snaha aplikovat zlozvyky z ineho jazyka do druheho. Klasicky C++ pristup robit vsetko rucne, alebo mat cely program v jednom subore sa v jave velmi nenosi (nastastie). V eclipse je ta halda ukonov par klavesovych skratiek.
Ani ve Vimu to není tolik úkonů, aby to stálo za řeč...
Zelenáč se zřejmě pokouší psát třídy, které jsou delší než 100 řádek. Pak mu z toho vznikají tyhle komplikace.
-
Toto je taky ten klasicky problem - snaha aplikovat zlozvyky z ineho jazyka do druheho. Klasicky C++ pristup robit vsetko rucne, alebo mat cely program v jednom subore sa v jave velmi nenosi (nastastie). V eclipse je ta halda ukonov par klavesovych skratiek. Ale hlavne nie je nutne davat to do samotnych suborov. Co sa tyka nejakej absencie na eventy - .net bezi uz aj na linuxe, v c# mate delegatov, tak sa nemusite trapit s javou ked vas neoslovila...
Prý se v Javě příliš nenosí... už jsem si hezkých pár knihoven stáhnul a chytal mě amok, když jsem chtěl reagovat v nějaké na eventu v anonymně vytvořené instanci a vygenerovalo se mi 15 metod k implementaci.
Kit: ne právěže nepíšu víc než 100 řádků na třídu. To že někde vznikne 20 událostí neznaméná, že ta třída musí mít stovky řádků. Bude to třída, která zaobaluje celou hierarchii tříd a tvoří k ní takový finální handler.
-
Takže dal jsem dokupy s vaší pomocí toto řešení:
Rozhraní k událostem vyvolaným v objektu vytvořím pomocí Interfacu, kterého bude implementovat Abstraktní třída. Čili udělám to tak, jak to dělá Swing. To je docela hezké řešení.
Teď ústavičné psaní AddLister a dalších: zde by se tedy mohlo dědit z nějaké třídy, která bude mít ty metody a atributy již napsány. Místo psaní vlastní mě napadá použít třídu Observable. Je to dobrý nápad?
-
Není to dobrý nápad, chtělo by to nějakou generickou třídu Observable<E>
-
2. Ad Třída nemá mít 20 událostí a pokud ano, je něco blbě. Jsem lenivý a tak si značně ulehčím odpověď na tento žvást: Každé přinejmenším GUI je miriáda událostí.
Není přece nutné všech 20 událostí obsluhovat v jedné obludné třídě. Ta třída si prostě zaslouží rozdělení do více menších tříd dle kompetencí.
Existuji i vyjimky. Napriklad parsery anebo cokoliv co ma v sobe nejaky stavovy automat. Samozrejme, ze muzete i DFA rozdelit do desitek trid, ale vysledek bude nejspis hure udrzovatelny. Podobne se to s implementaci nejakeho sitoveho protokolu.
-
Není přece nutné všech 20 událostí obsluhovat v jedné obludné třídě. Ta třída si prostě zaslouží rozdělení do více menších tříd dle kompetencí.
Existuji i vyjimky. Napriklad parsery anebo cokoliv co ma v sobe nejaky stavovy automat. Samozrejme, ze muzete i DFA rozdelit do desitek trid, ale vysledek bude nejspis hure udrzovatelny. Podobne se to s implementaci nejakeho sitoveho protokolu.
I stavový automat se zpravidla dá napsat rozumně tak, aby obsluha stavu byla jedním příkazem a na jednom řádku. Pokud těch stavů je 200, tak metoda holt bude mít 200+něco řádek. Nebudu to řezat jen kvůli tomu, abych se přísně držel nějakého pravidla, které by v takovém případě neplnilo svůj účel - přehlednost kódu.
Takových metod je však minimum a proto se na ně dají uplatnit výjimky z jinak přísných pravidel.
-
Takže přidal jsem si:
package gld.util;
import java.util.ArrayList;
import java.util.Collection;
/** Simple observable with generics
*/
public class Observable<T> {
protected Collection<T> observers = new ArrayList<>();
public void addObserver(T observer) {
synchronized (observers) {
if (!observers.contains(observer)) {
observers.add(observer);
}
}
}
public void removeObserver(T observer) {
synchronized (observers) {
observers.remove(observer);
}
}
public void clearObservers() {
synchronized (observers) {
this.observers.clear();
}
}
}
Nicméně s tímto vyvstává další problém a to je multinásobné dědičnost. Tedy nevyvstává, protože v Javě tato možnost není, v C++ je. Já si totiž podědím tuto třídu, ale to mi znemožní, abych si kupříkladu udělal třídu, rozšiřující nějakou jinou knihovní třídu. Příklad: budu chtít rozšířit třídu Socket o události. Potom nemůžu už dědit tuto mou třídu. To je past vedle pasti ta Java.
-
protected Collection<T> observers = new ArrayList<>();
Proč tu kolekci observers nemáš synchronized?
-
Je účelem tohoto tématu, abyste předváděl, jak to opravdu neumíte a nechcete umět, nebo se chcete něco naučit? Zatím to vypadá na to první.
-
protected Collection<T> observers = new ArrayList<>();
Proč tu kolekci observers nemáš synchronized?
A jak ji mám mit synchronized? Vím že metody se dají dát jako synchronized, v tom případě se zamyká tuším celý objekt, ale atributy?
-
protected Collection<T> observers = new ArrayList<>();
Proč tu kolekci observers nemáš synchronized?
Ono je to celé špatně. Místo synchronized kolekce by bylo lepší použít některou z kolekcí java.util.concurrent. Navíc tam nemá žádné čtení kolekce, takže je ta kolekce úplně zbytečná. Místo toho si stěžuje, že nemá vícenásobnou dědičnost, aby si v tom kódu udělal ještě větší guláš.
Řešením by byla třída, která bude obhospodařovat posluchače – bude je umět zaregistrovat a odregistrovat a bude umět všem registrovaným posluchačům poslat zprávu. Zároveň si ošetří konkurenční přístup. To je kód právě pro jednu třídu, není potřeba žádná vícenásobná dědičnost a ta třída se použije ve třídách, které potřebují posílat nějaké události registrovaným posluchačům. (Ano, v jiných jazycích by se to dalo řešit vícenásobnou dědičností místo kompozice, ale to by bylo porušení principu single responsibility.)
-
Řešením by byla třída, která bude obhospodařovat posluchače – bude je umět zaregistrovat a odregistrovat a bude umět všem registrovaným posluchačům poslat zprávu. Zároveň si ošetří konkurenční přístup. To je kód právě pro jednu třídu, není potřeba žádná vícenásobná dědičnost a ta třída se použije ve třídách, které potřebují posílat nějaké události registrovaným posluchačům. (Ano, v jiných jazycích by se to dalo řešit vícenásobnou dědičností místo kompozice, ale to by bylo porušení principu single responsibility.)
Jenže to budu muset do jediného objektu zakomponovat více parametrů, v případě že jich posílám víc. Můžeš mi říct, jak si takovuto skvělou věcí pomůžu a jak mi toto vylepší kód?
-
jak vravi Filip Jirsak: staci pouzit CopyOnWriteArrayList. to je thread safe list. nemusite synchronized(). je to lepsie nez bordel so synchronized a collections.synchronizesList ktore su blbe
ad viacnasobna dedicnost: namiesto nej delegation
[tt]interface Observable {
addObserver(o)
removeObserver(o)
}
class DelegatingObservable implements Observable {
Collection observers = new copyonwritearraylist();
addObserver(o) {
observers.add(o)
}
removeObserver(o) {
observers.add(o)
}
}
class Socket implements Observable {
DelegatingObservable delegate = new DelegatingObservable();
addObserver(o) {
delegate.addObserver(o)
}
removeObserver(o) {
delegate.add(o)
}
}[/tt]
-
Zdravím,
zajímalo by mně, jak by zdejší Java guru vyřešili tohle:
Dělám si client-server komunikační aplikaci, kterážto se později vyvine do P2P. To vyžaduje knihovnu, která obstarává naslouchání na portu (SocketServer) a dále obsluhu vzniklých Socketů (keepAlive, odesílání práv, příjem zpráv, rušení připojení, info o délce neaktivity socketů, atd.). Dále je třeba vytvořit další zaobalení těchto tříd a vytvořit třídu která v sobě sdružuje další funkcionality: typ odeslané zprávy (číže protokoly pro: chat, soubor, signalizace). A vzniknout další a další.
Je zřejmé, že takováto věc vyžaduje spoustu událostí, píše-li se správně objektově a to je prostě v Javě boží utrpení. Pořád dokolečka psát: listener kolekce, metody pro vyvolání událostí, foreache, interfacy. Obzvláště ty interfacy jsou velká lahůdka: co když třída má 20 událostí a já chci v jiné třídě reagovat pouze na 1? To musím buďto:
1. Napsat jednotný IListener interface kde budou všechny události k dané třídě. To vede k tomu, že pakliže v nějaké jiné třídě potřebuji jen události 2, stejně se mi jich tam bouchne dalších 18 které tam budou v souboru nevyužité strašit.
2. Napsat pro každou jednu událost jeden interface. No tak to tedy hodně štěstí při vývoji takovéto architektury, protože každý interface musí být v samostatném souboru, což je obrovská halda úkonů, která je k tomu nutná.
Prostě takové aplikace je plná událostí, nejde to elegantně řešit nijak jinak. Co s takovýmto hrozivým jazykem?
PS: Píšu to v Javě ze studijích důvodů, jinak bych to napsal hned v Qt.
Na architekturu té aplikace se díváte ze špatné strany, nejdříve je třeba zvolit typ architektury, z toho vám vyplynou požadavky na nějaké třídy zajišťující tuto abstraktní vrstvu, v této fázi žádné eventy neřešíte. Například "pipe and filter architecture", "enterprise process-centric" nebo vámi preferovanou "event-centric"
Pak vytvoříte výkonnou část eventů, tedy to co se má udělat, když daná událost nastane, a event je jen lepidlo, mezi těmito vrstvami, které jsou prakticky na sobě nezávislé.Výkonná část eventu by měl být objekt, který lze zkonstruovat třeba i v rámci skriptu, který importuje data do aplikace mimo UI, jen ze vstupních dat uložených v xml, nebo db. Rozhodně by výkonná část aplikace neměla být závislá na UI a nějak s ním viditelně provázaná.
-
Proč tu kolekci observers nemáš synchronized?
A jak ji mám mit synchronized? Vím že metody se dají dát jako synchronized, v tom případě se zamyká tuším celý objekt, ale atributy?
Stačí trochu zagooglit, ne?
private Collection<T> observers = Collections.synchronizedList(new ArrayList<>());
BTW: Trochu mi uniká, proč děláš kolekci observerů a ne jejich abonentů...
-
Rozhodně by výkonná část aplikace neměla být závislá na UI a nějak s ním viditelně provázaná.
Tak tomu nerozumím. Kde jste nabral dojem, že je má aplikace závislá na UI? Já právěže dělám UI úplně odlišené od zbytku. Já mám přece architekturu vybranou už od začátku - řízenou událostmi. A mám v tom celkem pořádek, až na to, že není v Javě snadné psát pořádně eventy.
Teda já čím dál víc zabrouzdávám do útrob, tím míň se divím, že je tak v oblibě C#. Tam bych totiž nic takového nemusel řešit, vážně ne. Eventy jsou přece tak důležitá věc v OOP. Ok, Java je pole neorané, beru.
-
Tam bych totiž nic takového nemusel řešit, vážně ne. Eventy jsou přece tak důležitá věc v OOP. Ok, Java je pole neorané, beru.
vsak to sa ani v jave neriesi: hore ste mali 3 a viac prikladov ako sa to realne pouziva
dajte mi kus kodu v C# ja vam ho prepisem do javy :-)
ak vam chybaju delegaty tak to je preto ze az do java 8 neboli lambdy a java je konzervativna vzhladom k syntax sugar
-
Rozhodně by výkonná část aplikace neměla být závislá na UI a nějak s ním viditelně provázaná.
Tak tomu nerozumím. Kde jste nabral dojem, že je má aplikace závislá na UI? Já právěže dělám UI úplně odlišené od zbytku. Já mám přece architekturu vybranou už od začátku - řízenou událostmi. A mám v tom celkem pořádek, až na to, že není v Javě snadné psát pořádně eventy.
Teda já čím dál víc zabrouzdávám do útrob, tím míň se divím, že je tak v oblibě C#. Tam bych totiž nic takového nemusel řešit, vážně ne. Eventy jsou přece tak důležitá věc v OOP. Ok, Java je pole neorané, beru.
No UI by se mělo dělat až nakonec. Událost není kliknutí na tlačítko Objednat, ale nová objednávka. A abyste naprogramoval reakci na událost nová objednávka, k tomu žádné UI nepotřebujete. Systém by měl být funkční i bez UI, jen s přístupem do vstupních dat v souborech, nebo v db.
Pokud k UI doděláváte akce, které přímo pracují s DB (více méně skrytě, přes nějaké ad hoc objekty) a primární je UI, dostanete se do problémů v každém jazyce.
-
Nejsem Java guru, ale, pokud chceš odpověď jak na to, řeknu ti: nepoužívej Javu. Java má jednu ohromnou výhodu, běží všude a je plně zpětně kompatibilní. Dnešní programy v Javě poběží i za deset let na jakékoli super hyper funky procesorové architektuře která se zrovna rozhodne dobít svět. Na druhou stranu, chybné rozhodnutí před 15 lety ovlivňuje Javu doteď. Kuli bezpečnosti třeba nejde udělat override operátorů, nejsou pořádné jak ty říkáš eventy, a není toho asi mnohem víc, zas tak se ale o svět Javy nezajímám, takže nebudu víc kecat.
-
Nejsem Java guru, ale, pokud chceš odpověď jak na to, řeknu ti: nepoužívej Javu. Java má jednu ohromnou výhodu, běží všude a je plně zpětně kompatibilní. Dnešní programy v Javě poběží i za deset let na jakékoli super hyper funky procesorové architektuře která se zrovna rozhodne dobít svět. Na druhou stranu, chybné rozhodnutí před 15 lety ovlivňuje Javu doteď. Kuli bezpečnosti třeba nejde udělat override operátorů, nejsou pořádné jak ty říkáš eventy, a není toho asi mnohem víc, zas tak se ale o svět Javy nezajímám, takže nebudu víc kecat.
Moje rada je: nenecaht si radit od lidi, co tomu nerozumeji.
-
Ty „eventy” z Qt se správně nazývají signály a Java je samozřejmě taky umí (https://github.com/retuxx/sig4j) ;)
-
Stačí trochu zagooglit, ne?
private Collection<T> observers = Collections.synchronizedList(new ArrayList<>());
BTW: Trochu mi uniká, proč děláš kolekci observerů a ne jejich abonentů...
Což je z implementací s bezpečným konkurenčním přístupem to nejhorší řešení. Protože se zamyká jakýkoli přístup k té kolekci, což není potřeba. Z té kolekce se asi bude mnohem častěji číst a jenom málokdy se do ní bude zapisovat. A je úplně zbytečné, aby na sebe jednotliví čtenáři čekali, klidně mohou číst paralelně, konkurenční přístup je potřeba hlídat jenom v okamžiku, kdy se do kolekce zapisuje, plus v případě událostí bude potřeba asi synchronizovat tak, aby čtení z kolekce ve workflow navazujícím na přidání posluchače vždy vracelo i toho nově přidaného posluchače – jinak by se mohly některé události ztrácet. Obvykle se to dělá ve stejném vláknu (i kvůli optimalizaci), ale bůhví, jaké s tím má Zelenáč plány. Ale ani tenhle požadavek nevyžaduje řadit veškeré přístupy ke kolekci za sebe.
-
vsak to sa ani v jave neriesi: hore ste mali 3 a viac prikladov ako sa to realne pouziva
A přesto, řekni mi třeba, proč k java.util.Observable neexistuje generická varianta, nebo varianta tvá s tím delegátem?
K čemu konkrétně je to java.util.Observable, vysvětli mi ten jeho význam. Pokud to budu dědit, zamezím si tím dědění z jinačí třídy. Není k tomu ani IObservable, aby se to implementovalo přes delgáta, jak ty říkáš.
Říkaš že přepíšeš do Javy. Ok tady máš variantu v Qt:
#include <QObject>
class Counter : public QObject
{
Q_OBJECT
public:
Counter() { m_value = 0; }
int value() const { return m_value; }
public slots:
void setValue(int value);
signals:
void valueChanged(int newValue);
private:
int m_value;
};
void Counter::setValue(int value)
{
if (value != m_value) {
m_value = value;
emit valueChanged(value);
}
}
// někde v main:
Counter a, b;
[b]QObject::connect(&a, SIGNAL(valueChanged(int)), &b, SLOT(setValue(int)));[/b]
a.setValue(12); // a.value() == 12, b.value() == 12
b.setValue(48); // a.value() == 12, b.value() == 48
-
Jenže to budu muset do jediného objektu zakomponovat více parametrů, v případě že jich posílám víc. Můžeš mi říct, jak si takovuto skvělou věcí pomůžu a jak mi toto vylepší kód?
Jakých víc parametrů, koho posíláte víc? Chcete z jednoho objektu posílat různé typy událostí? No tak si prostě implementujte třídu s metodami zaregistrujPosluchace(TypUdalosti, Posluchac), odregistrujPosluchace(typUdalosti, Posluchac) a posliUdalost(TypUdalosti, Data), implementaci téhle třídy si vložte do každé třídy, která má umět posílat události, a delegujte na tu třídu volání metod zaregistrujPosluchace a odregistrujPosluchace. A ty dvě metody si dejte do interface, který označí všechny třídy, které umí posílat události.
-
A přesto, řekni mi třeba, proč k java.util.Observable neexistuje generická varianta, nebo varianta tvá s tím delegátem?
K čemu konkrétně je to java.util.Observable, vysvětli mi ten jeho význam. Pokud to budu dědit, zamezím si tím dědění z jinačí třídy. Není k tomu ani IObservable, aby se to implementovalo přes delgáta, jak ty říkáš.
Observable je socket, ne ta třída, ve které ten socket je.
-
A přesto, řekni mi třeba, proč k java.util.Observable neexistuje generická varianta, nebo varianta tvá s tím delegátem?
K čemu konkrétně je to java.util.Observable, vysvětli mi ten jeho význam. Pokud to budu dědit, zamezím si tím dědění z jinačí třídy. Není k tomu ani IObservable, aby se to implementovalo přes delgáta, jak ty říkáš.
Observable je socket, ne ta třída, ve které ten socket je.
Pardon, v Qt terminologii se tomu říká signál. (Interně MOC taky vygeneruje instance pro každý signál, který si drží posluchače, tj. observery.)
-
Nejsem Java guru, ale, pokud chceš odpověď jak na to, řeknu ti: nepoužívej Javu. Java má jednu ohromnou výhodu, běží všude a je plně zpětně kompatibilní. Dnešní programy v Javě poběží i za deset let na jakékoli super hyper funky procesorové architektuře která se zrovna rozhodne dobít svět. Na druhou stranu, chybné rozhodnutí před 15 lety ovlivňuje Javu doteď. Kuli bezpečnosti třeba nejde udělat override operátorů, nejsou pořádné jak ty říkáš eventy, a není toho asi mnohem víc, zas tak se ale o svět Javy nezajímám, takže nebudu víc kecat.
Běží všude ... stejně blbě. Sice může běžet na různých (budoucích) architekturách, ale třeba na ARM je výkon mizerný. Dobře škálovatelné je do budoucnosti Go. Čím dál víc firem láme nad Javou hůl.
-
A přesto, řekni mi třeba, proč k java.util.Observable neexistuje generická varianta, nebo varianta tvá s tím delegátem?
K čemu konkrétně je to java.util.Observable, vysvětli mi ten jeho význam. Pokud to budu dědit, zamezím si tím dědění z jinačí třídy. Není k tomu ani IObservable, aby se to implementovalo přes delgáta, jak ty říkáš.
Observable je socket, ne ta třída, ve které ten socket je.
No to jsi trochu přestřelil, ne? Tady jsem našel, co observable je:
http://www.javaworld.com/article/2077258/learn-java/observer-and-observable.html
Pozůstatek z roku 1996, takže asi tak. To je hrozné.
-
Java je frustrující. Kdybych byl programátor střižený s umělcem a měl stvárnit Javu, nakreslil bych starou almaru.
(http://img2.hyperinzerce.cz/x-cz/inz/6984/6984074-starozitni-almara-3.jpg)
-
(http://i.imgur.com/v5IK8dv.jpg)
-
(http://i.imgur.com/v5IK8dv.jpg)
;D ;D ;D výstižné
-
Nejsem Java guru, ale, pokud chceš odpověď jak na to, řeknu ti: nepoužívej Javu. Java má jednu ohromnou výhodu, běží všude a je plně zpětně kompatibilní. Dnešní programy v Javě poběží i za deset let na jakékoli super hyper funky procesorové architektuře která se zrovna rozhodne dobít svět. Na druhou stranu, chybné rozhodnutí před 15 lety ovlivňuje Javu doteď. Kuli bezpečnosti třeba nejde udělat override operátorů, nejsou pořádné jak ty říkáš eventy, a není toho asi mnohem víc, zas tak se ale o svět Javy nezajímám, takže nebudu víc kecat.
Běží všude ... stejně blbě. Sice může běžet na různých (budoucích) architekturách, ale třeba na ARM je výkon mizerný. Dobře škálovatelné je do budoucnosti Go. Čím dál víc firem láme nad Javou hůl.
To je přinejmenším hodně zavádějící tvrzení. Výkonnostní problémy se týkají pouze OpenJDK, které neumí využít ThumbEE (nemá JIT) ani hard-float. Oracle Java je výrazně rychlejší (https://blogs.oracle.com/jtc/entry/comparing_jvms_on_arm_linux).
No to jsi trochu přestřelil, ne? Tady jsem našel, co observable je:
http://www.javaworld.com/article/2077258/learn-java/observer-and-observable.html
Pozůstatek z roku 1996, takže asi tak. To je hrozné.
V signál-slotové architektuře je observable signál.
Qt včetně signálů a slotů je z roku 1991. Fakt hrůza.
-
Mimochodem všiml sis toho sig4j (https://github.com/retuxx/sig4j), co jsem tu posílal? V Javě můžeš udělat úplně stejné božské objekty (https://en.wikipedia.org/wiki/God_object) jako v Qt ;) (Ne že by bylo nutné v Qt dělat božské objekty. Ale když jeden objekt má 20 nezávislých událostí, že by musel mít tolik listenerů…)
-
Mimochodem všiml sis toho sig4j (https://github.com/retuxx/sig4j), co jsem tu posílal? V Javě můžeš udělat úplně stejné božské objekty (https://en.wikipedia.org/wiki/God_object) jako v Qt ;) (Ne že by bylo nutné v Qt dělat božské objekty. Ale když jeden objekt má 20 nezávislých událostí, že by musel mít tolik listenerů…)
Podle pravidla SOLID má každá objekt vykonávat jednotkovou činnos. Potom, mám-li objekt, který vyvovolává 20 událostí, dokaž mi, že nutně nevykonává jendotkovou činnost, ve smyslu tom, že propojuje objekty a tvoří k nim jednotné rozhraní. To taky může být považováno za jednotkový úkon.
-
Jeste jednou ten Observer a Observable. Tato funkcionalita:
1.) Je obsažena přímo v knihovně, čili linkuje způsob, jak psát program, to je pozitivní věc.
2.) Musím z ní však dědit, neboť k ní není napsáno rozhraní. Leda bych ji dal při implementaci do třídy jako public, což není ok. To je negativní věc.
3.) Musím pracně zajistit přenos argumentů, tj. jak třeba v Object přenesu Socket, String a ještě třeba Integer? To si musím k tomu extra vytvářet novou třídu, teď tuto třídu musím nějak delegovat, a v update(Observable o, Object obj) to musím roztypovat, protože typů objektů budu chtít přenášet v rámci jednoho Observable víc. To je velice negativní.
Ad 3.) jaké poskutyje Javí knihovna instatní řešení k této situaci? Poskytuje vůbec nějaké?
-
Nejsem Java guru, ale, pokud chceš odpověď jak na to, řeknu ti: nepoužívej Javu. Java má jednu ohromnou výhodu, běží všude a je plně zpětně kompatibilní. Dnešní programy v Javě poběží i za deset let na jakékoli super hyper funky procesorové architektuře která se zrovna rozhodne dobít svět. Na druhou stranu, chybné rozhodnutí před 15 lety ovlivňuje Javu doteď. Kuli bezpečnosti třeba nejde udělat override operátorů, nejsou pořádné jak ty říkáš eventy, a není toho asi mnohem víc, zas tak se ale o svět Javy nezajímám, takže nebudu víc kecat.
Běží všude ... stejně blbě. Sice může běžet na různých (budoucích) architekturách, ale třeba na ARM je výkon mizerný. Dobře škálovatelné je do budoucnosti Go. Čím dál víc firem láme nad Javou hůl.
To je přinejmenším hodně zavádějící tvrzení. Výkonnostní problémy se týkají pouze OpenJDK, které neumí využít ThumbEE (nemá JIT) ani hard-float. Oracle Java je výrazně rychlejší (https://blogs.oracle.com/jtc/entry/comparing_jvms_on_arm_linux).
Ano, je rychlejší, ale pořád to je bída, aspoň na 32-bitových procesorech, s 64-bitovými zkušenosti nemám.
-
Podle pravidla SOLID má každá objekt vykonávat jednotkovou činnos. Potom, mám-li objekt, který vyvovolává 20 událostí, dokaž mi, že nutně nevykonává jendotkovou činnost, ve smyslu tom, že propojuje objekty a tvoří k nim jednotné rozhraní. To taky může být považováno za jednotkový úkon.
Máš nějaký příklad? Protože tohle hodně, hodně smrdí lasagnemi.
Ad 3.) jaké poskutyje Javí knihovna instatní řešení k této situaci? Poskytuje vůbec nějaké?
Typicky se to předává v tom Observable (jak to bylo vidět i v té ukázce, kterou jsi tady posílal). Ten objekt je spíš tag na rozlišení více událostí než hodnota a moc se nepoužívá (i když tedy ten interface nijak neurčuje, co tam má být, teoreticky to může být i hodnota).
Ano, je rychlejší, ale pořád to je bída, aspoň na 32-bitových procesorech, s 64-bitovými zkušenosti nemám.
Měřil jsi to někdy? (Psal jsi vůbec někdy něco v Javě?)
Android má naprostou většinu UI taky v Javě. Dokonce většina aplikací pro Android plynule poběží s 16 až 24 MiB haldy (https://developer.android.com/reference/android/app/ActivityManager.html#getMemoryClass()). Hodně štěstí s takovými limity v KDE ;)
-
Ano, je rychlejší, ale pořád to je bída, aspoň na 32-bitových procesorech, s 64-bitovými zkušenosti nemám.
Měřil jsi to někdy? (Psal jsi vůbec někdy něco v Javě?)
Android má naprostou většinu UI taky v Javě. Dokonce většina aplikací pro Android plynule poběží s 16 až 24 MiB haldy (https://developer.android.com/reference/android/app/ActivityManager.html#getMemoryClass()). Hodně štěstí s takovými limity v KDE ;)
Kdybych to neměřil, tak o tom nepíšu. A bavíme se o Javě od Oraclu, ta v Androidu není. Jinak dost blbý argument vzhledem k tomu, jak Android furt laguje, ale to je momentálně off topic. Až někdo ukáže, že se Java na armv7 rychlostí aspoň blíží C++/Go/Swiftu, rád se na kód podívám. Jinak zůstanu u svých zkušeností (jinak se tu o tom už diskutovalo včetně kódu a testech na RPi2).
-
Java je frustrující. Kdybych byl programátor střižený s umělcem a měl stvárnit Javu, nakreslil bych starou almaru.
Je pozoruhodné, jak tady opakovaně předvádíte, že v Javě vůbec programovat neumíte, a opakovaně z toho viníte Javu. Držte se radši toho Qt, tam není taková konkurence – sice nejste dobrý programátor, ale aspoň budete mít tu výhodu, že znáte Qt.
-
Jeste jednou ten Observer a Observable. Tato funkcionalita:
1.) Je obsažena přímo v knihovně, čili linkuje způsob, jak psát program, to je pozitivní věc.
2.) Musím z ní však dědit, neboť k ní není napsáno rozhraní. Leda bych ji dal při implementaci do třídy jako public, což není ok. To je negativní věc.
3.) Musím pracně zajistit přenos argumentů, tj. jak třeba v Object přenesu Socket, String a ještě třeba Integer? To si musím k tomu extra vytvářet novou třídu, teď tuto třídu musím nějak delegovat, a v update(Observable o, Object obj) to musím roztypovat, protože typů objektů budu chtít přenášet v rámci jednoho Observable víc. To je velice negativní.
Ad 3.) jaké poskutyje Javí knihovna instatní řešení k této situaci? Poskytuje vůbec nějaké?
AD 3. To je výhoda Javy, nutí programátory psát programy slušně, a nutí je přemýšlet, nesklouzávat do rutiny, neumožňuje jim se vyžívat ve tvoření individuálního ornamentalního kódu (typicky C, Bash), brání jim psát efektivně, ale nesrozumitelně, vytvářet v kódu barokní kudrlinky, což je taky výhoda.
-
Jeste jednou ten Observer a Observable. Tato funkcionalita:
1.) Je obsažena přímo v knihovně, čili linkuje způsob, jak psát program, to je pozitivní věc.
2.) Musím z ní však dědit, neboť k ní není napsáno rozhraní. Leda bych ji dal při implementaci do třídy jako public, což není ok. To je negativní věc.
3.) Musím pracně zajistit přenos argumentů, tj. jak třeba v Object přenesu Socket, String a ještě třeba Integer? To si musím k tomu extra vytvářet novou třídu, teď tuto třídu musím nějak delegovat, a v update(Observable o, Object obj) to musím roztypovat, protože typů objektů budu chtít přenášet v rámci jednoho Observable víc. To je velice negativní.
Ad 3.) jaké poskutyje Javí knihovna instatní řešení k této situaci? Poskytuje vůbec nějaké?
AD 3. To je výhoda Javy, nutí programátory psát programy slušně, a nutí je přemýšlet, nesklouzávat do rutiny, neumožňuje jim se vyžívat ve tvoření individuálního ornamentalního kódu (typicky C, Bash), brání jim psát efektivně, ale nesrozumitelně, vytvářet v kódu barokní kudrlinky, což je taky výhoda.
To si děláte vážně legraci, nutí programátory psát slušné programy? Kolik vám je let, dělal jste někdy něco v .NET? To byste totiž zažil, co to je, když platforma nutí, nebo spíše vede, k tomu psát slušné programy a dělat slušné knihovny, které uživatel může okamžitě začít používat.
-
package cz.root;
public class Counter {
public interface ValueChangedListener {
void valueChanged(int newValue);
}
private ValueChangedListener valueChangedListener = (value -> {});
private int value;
public int getValue() {
return value;
}
public void setValue(int newValue) {
if(this.value != newValue) {
this.value = newValue;
fireValueChanged(this.value);
}
}
private void fireValueChanged(int newValue) {
valueChangedListener.valueChanged(newValue);
}
public void setValueChangedListener(ValueChangedListener valueChangedListener) {
this.valueChangedListener = valueChangedListener;
}
public static void main(String[] args) {
Counter a = new Counter();
Counter b = new Counter();
a.setValueChangedListener(b::setValue);
a.setValue(12);
System.out.printf("a = %d, b = %d\n", a.getValue(), b.getValue());
b.setValue(48);
System.out.printf("a = %d, b = %d\n", a.getValue(), b.getValue());
}
}
Jinak dost blbý argument vzhledem k tomu, jak Android furt laguje, ale to je momentálně off topic.
a uz ste skusil na tom istom procesore iOS alebo windows phone?
Čím dál víc firem láme nad Javou hůl.
a to su ktore?
-
To si děláte vážně legraci, nutí programátory psát slušné programy? Kolik vám je let, dělal jste někdy něco v .NET? To byste totiž zažil, co to je, když platforma nutí, nebo spíše vede, k tomu psát slušné programy a dělat slušné knihovny, které uživatel může okamžitě začít používat.
Cim mensi znalosti, tim silnejsi nazory. O Jave ocividne vis houbeles (to je OK, kazdy nejak zacinal), ale uz v tom mas jasno.
-
perceptronovi děkuju za kód.
Ono ten root zase enzklamal. Člověk se tu na něco zeptá (jak implemenovat eventy), trochu přidrzle ale ono by to dopadlo stejně tak či tak, a všichni tu pindají různě, místo toho aby někdo napsal, že interface mám implementovat jen s jednou metodou, čímž z něj udělám functional interface, a pak si naň můžu přímočaře připojit metody z trida::metoda, a že tato světoborná funkcionalita, existující v jiných jazycích už řadu let, byla přidána do javy 1.8. Opravdu pozoruhodné, ale na rootu klasika. Kdyby to zde ti světoborní javisti napsali hned v prvním příspěvku, nemusel tady zase vzniknout takový flame.
Dobře, takže Observable a Observer je zastaralá věc, zřejmě se drží v knihovně z důvodu zpětné kompatibility, ale nemá žádnou náhradu. To není žádná frajeřina, ani svoboda, že si programovou architekturu bude psát kdo chce jak chce a že ani v knihovně Javy není žádný standard pro eventy - tomu se říká bordel. Jeden si implementuje do knihovny eventy tak, druhý onak. Rozšiřuje to množinu "pro jednu a tutéž věc, několik různých řešení", která je podmnožinou množiny "už se nevyznám v tom bordelu", což jde dobře zažít, když někdo používá java knihovny z githubu. Ty jsou tak na úrovni starších knihoven do C++, v kterých se používají ústvičně jiné notace, dle chuti a nálady každého programátora.
Možná že to není taková nevýhoda pro korporace, které si vyvíjí vlastní softy a mají vlastní firemní standardy pro implementaci např. právě event. POČKAT.... ŘEKL JSEM PRO KORPORACE? Ono se někde jinde Java používá než v korporacích? AHA, NE, NEPOUŽÍVÁ, tak to jsem trefil do černého.
-
To si děláte vážně legraci, nutí programátory psát slušné programy? Kolik vám je let, dělal jste někdy něco v .NET? To byste totiž zažil, co to je, když platforma nutí, nebo spíše vede, k tomu psát slušné programy a dělat slušné knihovny, které uživatel může okamžitě začít používat.
Cim mensi znalosti, tim silnejsi nazory. O Jave ocividne vis houbeles (to je OK, kazdy nejak zacinal), ale uz v tom mas jasno.
Pakliže ty jsi nikdy nedělal v .NETtech, tak v tom máš až přespříliš jasno ty, ne já. Je jedno jak dobře umíš Javu, když nejsi schopen srovnání. Tak nemachruj.
-
V mém ročníku na vš bylo takových 100 lidí, ale na jedné ruce bych spočítal ty, kteřížto jsou Javisti, vč. mě. Javu nikdo nechce dělat. Jo, z vedlejší univerzity, tam je javistů dost. Víš proč? Protože tam C# ani nemají, nikdy ho nezažili. U nás, kdo zažil C#, je pro něj Java shit. Naštěstí já jsem hrdý člověk a rád si dělám věci těžší, tak je ze mě Javista :D a to ti řeknu rovnou, že C#je tak o dvě třídy dál než Java, ale já bych nerad pracoval pro Microsoft, obzvlášť ne po tom, kam došly W10.
-
nemusel tady zase vzniknout takový flame.
keby ste napady neignorovali (signals 4 j) a vyjadrili sa k nim namiesto frajerovania, mali by ste vysledok skor
AHA, NE, NEPOUŽÍVÁ, tak to jsem trefil do černého.
ste si isty ze sa riadite svojimi vlastnymi pravidlami diskusie? a co capslock, zasekava, zasekava?
Java veci z hlavy: elasticsearch, hbase, akka (to viac scala), spark, android
-
Jenže. Na Sig4j jsem se díval a nezdálo se mi to úpříliš poplární, navíc to vyžaduje verzi 1.8. Ne že bych chtěl populární věci, ale sig4j nikdy nebude pořádný standard. Kdybych chtěl svou knihovnu někomu poskytnout, musel bych ho navíc nutit používat rovněž sig4j, tedy mu nařizovat, jak má zpracovávat eventy. Já chtěl nějaké standardní řešení. CAPS LOCK
-
Jenže. Na Sig4j jsem se díval a nezdálo se mi to úpříliš poplární, navíc to vyžaduje verzi 1.8. Ne že bych chtěl populární věci, ale sig4j nikdy nebude pořádný standard. Kdybych chtěl svou knihovnu někomu poskytnout, musel bych ho navíc nutit používat rovněž sig4j, tedy mu nařizovat, jak má zpracovávat eventy. Já chtěl nějaké standardní řešení. CAPS LOCK
A Qt je standardní knihovna v ISO C++ odkdy?
-
V mém ročníku na vš bylo takových 100 lidí, ale na jedné ruce bych spočítal ty, kteřížto jsou Javisti, vč. mě. Javu nikdo nechce dělat. Jo, z vedlejší univerzity, tam je javistů dost. Víš proč? Protože tam C# ani nemají, nikdy ho nezažili. U nás, kdo zažil C#, je pro něj Java shit. Naštěstí já jsem hrdý člověk a rád si dělám věci těžší, tak je ze mě Javista :D a to ti řeknu rovnou, že C#je tak o dvě třídy dál než Java, ale já bych nerad pracoval pro Microsoft, obzvlášť ne po tom, kam došly W10.
Sice o tom vim houby ale je to shit.
-
V mém ročníku na vš bylo takových 100 lidí, ale na jedné ruce bych spočítal ty, kteřížto jsou Javisti, vč. mě. Javu nikdo nechce dělat. Jo, z vedlejší univerzity, tam je javistů dost. Víš proč? Protože tam C# ani nemají, nikdy ho nezažili. U nás, kdo zažil C#, je pro něj Java shit. Naštěstí já jsem hrdý člověk a rád si dělám věci těžší, tak je ze mě Javista :D a to ti řeknu rovnou, že C#je tak o dvě třídy dál než Java, ale já bych nerad pracoval pro Microsoft, obzvlášť ne po tom, kam došly W10.
To je dobre, aspon zbyde na ostatni vic penez...:D
-
Jenže. Na Sig4j jsem se díval a nezdálo se mi to úpříliš poplární, navíc to vyžaduje verzi 1.8. Ne že bych chtěl populární věci, ale sig4j nikdy nebude pořádný standard. Kdybych chtěl svou knihovnu někomu poskytnout, musel bych ho navíc nutit používat rovněž sig4j, tedy mu nařizovat, jak má zpracovávat eventy. Já chtěl nějaké standardní řešení. CAPS LOCK
Standardní řešení je Message Service (https://en.wikipedia.org/wiki/Java_Message_Service), jen je to poměrně heavy-weight.
Existuje i knihovna pro starší Javu (http://eventbus.org/), která místo lambd a FunctionalInterface používá anotačními procesor.
Qt má MOC, takže ani nejde zkompilovat standardním kompilátorem. Velmi, velmi standardní…
-
Jenže. Na Sig4j jsem se díval a nezdálo se mi to úpříliš poplární, navíc to vyžaduje verzi 1.8. Ne že bych chtěl populární věci, ale sig4j nikdy nebude pořádný standard. Kdybych chtěl svou knihovnu někomu poskytnout, musel bych ho navíc nutit používat rovněž sig4j, tedy mu nařizovat, jak má zpracovávat eventy. Já chtěl nějaké standardní řešení. CAPS LOCK
Standardní řešení je Message Service (https://en.wikipedia.org/wiki/Java_Message_Service), jen je to poměrně heavy-weight.
Existuje i knihovna pro starší Javu (http://eventbus.org/), která místo lambd a FunctionalInterface používá anotačními procesor.
Qt má MOC, takže ani nejde zkompilovat standardním kompilátorem. Velmi, velmi standardní…
Podívej... díky za tyto informace, ale já na eventy nechci externí knihovnu. Jsem divnej, že na takovou základní věc, jako jsou eventy, nechci knihovnu? To má být přece nějak slušně obsažené v nativní knihovně Javy. je tam Observer a Observable. Fajn. Chtělo by to ale něco pořádnějšího. Bohatě by mi stačilo, kdyby tam byl interface IObservable, který by předepisoval metody z Observable. Opravdu by mi to stačilo ke štěstí. Kdybych byl jó rozmazlený, chtěl bych ještě Observable<T>. Chci opravdu tak moc, že chci pořádné standarní zázemí pro eventy přímo v nativní knihovně? Asi jo.
Celý počítač je plný event. Je to stroj, reaguje celý ve stylu Akce-Reakce, je to mechanismus. Slušný programovací jazyk, který říká že je OOP, by měl mít dobrou podporu pro eventy. Eventy jsou naprostý základ, tohle je principiální záležitost. V Javě nejsou implementovány přímo, a není pro ně ani pořádné zázemí v nativní knihovně. Jsem z toho opravdu nešťasten.
-
Jsem divnej, že na takovou základní věc, jako jsou eventy, nechci knihovnu?
ano, ste divny.
tldr; java nie je c# a z toho sa vam zasekava capslock
1) vymysleli ste si ze prave java musi byt ten jazyk, co to musi mat v stdlib.
2) vobec vam nevadi ze C ktorym tu machate nesplna vase kriteria (Qt neni stdlib, kompilacia nie je straightforward)
3) odmietate pouzit riesenie ktore ma rovnaky pocet riadkov ako to vase, ziadne zavislosti (ani na stdlib). ano, moje riesenie
4) odmietate pouzit ine napady lebo plati 1)
5) mate nejaku paranoju k cudzim knizniciam,k starsim verziam javy a ku korporatu, ale c# v korporate vam paradoxne nevadi
-
Jsem divnej, že na takovou základní věc, jako jsou eventy, nechci knihovnu?
ano, ste divny.
tldr; java nie je c# a z toho sa vam zasekava capslock
1) vymysleli ste si ze prave java musi byt ten jazyk, co to musi mat v stdlib.
2) vobec vam nevadi ze C ktorym tu machate nesplna vase kriteria (Qt neni stdlib, kompilacia nie je straightforward)
3) odmietate pouzit riesenie ktore ma rovnaky pocet riadkov ako to vase, ziadne zavislosti (ani na stdlib). ano, moje riesenie
4) odmietate pouzit ine napady lebo plati 1)
5) mate nejaku paranoju k cudzim knizniciam,k starsim verziam javy a ku korporatu, ale c# v korporate vam paradoxne nevadi
Vy jste mi tu dal řešení? To je řešení, které bude fungovat jen od v 1.8, co když si budu chtít třeba na RPi, nebo někam kde musí běžet starší verze Javy, portovat svoje knihovny? To je jedna věc. Druhá věc: vaše řešení neobsahuje elegantní způsob vyhnutí se ústavičné implementaci AddListerů, RemoveListenerů a dalších, protože to máte implementováno jen pro jednoho listenera. Vaše řešení ani není tak dobré jako to, co používá Swing u registrace listenera. Swing to má sice ukecanější, ale je to standardní, je to elegantní a kód vygeneruje eclipse. Potřebuji ještě vyřešit elegantně implementaci Observable třídy, abych se neupsal k smrti a aby to bylo vyřešeno standardně, ne tak, že si vymyslím nějakou svou třídu Observable. Nemám to rád u externích knihoven, když si to každý dělá jak se mu zlíbí, tak to nebudu dělat ani u sebe. Na zbytek nereaguju protože jsou to připomínky k něčemu, co já v principu buďto netvrdím, nebo to považuju za holý nesmysl (jako třeba že chci, aby Java měla v stdlib podporu pro události - ANO TO OPRAVDU CHCI, vždyť je naprosto elementární věc).
-
:-X
-
Jak dlouho zase bude trvat, než Vám dojde, že to je klasik, který na cokoli zareaguje "ale..." a přihodí dalších 100 důvodů, proč něco nejde?
(http://orig15.deviantart.net/29b2/f/2013/011/5/b/don__t_feed_the_troll___by_blag001-d5r7e47.png)
-
bude fungovat jen od v 1.8, co když si budu chtít třeba na RPi
Java 8 na RPi běží, naopak je to první oficiální plnohodnotná verze pro ARM procesory.
Jinak myslím, že vás tady nikdo nenutil psát v Javě, tak nechápu, proč pořád musíte fňukat, že vám to opravdu nejde. Tak to nedělejte, je spousta jiných lidí, kteří na rozdíl od vás programovat umí…
-
(https://www.grahamcluley.com/wp-content/uploads/2015/03/ask-toolbar-600.jpeg)
-
A co sa tak pozriet na https://github.com/ReactiveX/RxJava
-
Teď si hluboce urazil Filipa Jirsáka, který má Ask Toolbar ve svém prohlížeči vzorně nainstalován už řadu let.
-
A co sa tak pozriet na https://github.com/ReactiveX/RxJava
Díky, mrknu, to už vypadá zajímavěji než co postoval tuším sten.
-
na strane 6 sme sa dozvedeli ze to ma bezat na raspberry pi.
Vy jste mi tu dal řešení?
vasi kolegovia musia mat radost: bud vam vec naprogramuju alebo na nich otvorite stream nadavok :-)
ale kedze je s Vami sranda zasluzite si riesenie java 7.
package cz.root;
import java.util.Observable;
import java.util.Observer;
public class Counter {
public static class CounterObservable extends Observable {
private Counter counter;
public CounterObservable(Counter counter) {
if(counter == null) {
throw new NullPointerException("Counter must be set");
}
this.counter = counter;
}
/**
* Expose method as public to allow invocation
* from delegatees.
*/
@Override
public synchronized void setChanged() {
super.setChanged();
}
public Counter getCounter() {
return counter;
}
}
public static class CounterObserver implements Observer {
public final void update(Observable o, Object arg) {
if(o instanceof CounterObservable && arg instanceof Integer) {
onUpdate(((CounterObservable) o).getCounter(), (Integer) arg);
}
}
public void onUpdate(Counter counter, int newValue) {
// no-op
}
}
private CounterObservable observableDelegate = new CounterObservable(this);
private int value;
public int getValue() {
return value;
}
public void setValue(int newValue) {
if(this.value != newValue) {
this.value = newValue;
fireValueChanged(this.value);
}
}
private void fireValueChanged(int newValue) {
observableDelegate.setChanged();
observableDelegate.notifyObservers(newValue);
}
public CounterObservable asObservable() {
return this.observableDelegate;
}
public static void main(String[] args) {
Counter a = new Counter();
final Counter b = new Counter();
a.asObservable().addObserver(new CounterObserver() {
@Override
public void onUpdate(Counter counter, int newValue) {
b.setValue(newValue);
}
});
a.setValue(12);
System.out.printf("a = %d, b = %d\n", a.getValue(), b.getValue());
b.setValue(48);
System.out.printf("a = %d, b = %d\n", a.getValue(), b.getValue());
}
}
třeba že chci, aby Java měla v stdlib podporu pro události - ANO TO OPRAVDU CHCI, vždyť je naprosto elementární věc
ok
*) riesenie observable v stdlib vam nevyhovuje lebo viacnasobna dedicnost
*) prisposobit si ho nechcete lebo chcete standardne riesenie
*) pisat vlastne veci nechcete.
*) cudzie veci pouzit nechcete.
toto je dead end. mozete tu dupkat nozickami po capslocku ze vam chyba podpora signalov / viacnasobna dedicnost ale takto to vo vyvoji daleko nedotiahnete.
-
ked uz sme v reactive dimenziach tak spring riesenie. kontext sluzi ako event bus. counter publikuje eventy do kontextu, listenery ich vyberaju. mozete broadcoastovat, riesit asynchronne.
bezi aj na starom springu 2.5 z roku 2007. (v 4.2 je to este kratsie)
public class Counter {
public static class ValueChangedEvent extends ApplicationEvent {
public ValueChangedEvent(int newValue) {
super(newValue);
}
}
private ApplicationEventPublisher eventPublisher;
private int value;
public int getValue() {
return value;
}
public void setValue(int newValue) {
if(this.value != newValue) {
this.value = newValue;
fireValueChanged(this.value);
}
}
private void fireValueChanged(int newValue) {
if(eventPublisher != null) {
eventPublisher.publishEvent(new ValueChangedEvent(newValue));
}
}
public void setEventPublisher(ApplicationEventPublisher eventPublisher) {
this.eventPublisher = eventPublisher;
}
public static void main(String[] args) {
GenericApplicationContext context = new GenericApplicationContext();
context.refresh();
Counter a = new Counter();
a.setEventPublisher(context);
Counter b = new Counter();
context.addApplicationListener(new ApplicationListener() {
@Override
public void onApplicationEvent(ApplicationEvent e) {
if(e instanceof ValueChangedEvent) {
b.setValue((Integer) ((ValueChangedEvent) e).getSource());
}
}
});
a.setValue(12);
System.out.printf("a = %d, b = %d\n", a.getValue(), b.getValue());
b.setValue(48);
System.out.printf("a = %d, b = %d\n", a.getValue(), b.getValue());
}
}
-
A co sa tak pozriet na https://github.com/ReactiveX/RxJava
Díky, mrknu, to už vypadá zajímavěji než co postoval tuším sten.
Přesně tak, RxJava je dobrá cesta, divím se, že to tu tak zapadlo a tolik se vynalézá kolo
-
Vy jste mi tu dal řešení? To je řešení, které bude fungovat jen od v 1.8, co když si budu chtít třeba na RPi, nebo někam kde musí běžet starší verze Javy, portovat svoje knihovny?
RetroLambda (https://github.com/orfjackal/retrolambda)
Druhá věc: vaše řešení neobsahuje elegantní způsob vyhnutí se ústavičné implementaci AddListerů, RemoveListenerů a dalších, protože to máte implementováno jen pro jednoho listenera.
Nemusíte. Podívejte se na to, jak to řeší mnou odkazovaný EventBus, je tam jedna metoda subscribe a jedna unsubscribe pro všechny typy eventů. Další možností je použít any listener interface:
public class ClassWithManyListeners
{
// Předek všech listenerů
public interface Listener
{
// Listenery pro událost onFoo
public interface OnFoo
extends Listener
{
public void onFoo(String foo);
}
// Listenery pro událost onBar
public interface OnBar
extends Listener
{
public boolean onBar(Object bar);
}
}
// LinkedHashSet zaručuje pořadí při for-each. Pokud není potřeba, stačí jakýkoliv set
private final Set<Listener.OnFoo> onFoos = new LinkedHashSet<>();
private final Set<Listener.OnBar> onBars = new LinkedHashSet<>();
public void subscribe(Listener listener)
{
if (listener instanceof Listener.OnFoo)
onFoos.add((Listener.OnFoo)listener);
if (listener instanceof Listener.OnBar)
onBars.add((Listener.OnBar)listener);
}
public void unsibscribe(Listener listener)
{
onFoos.remove(listener);
onBars.remove(listener);
}
public void methodThatTriggersFoo()
{
String foo = "whatever";
for (Listeners.OnFoo f : onFoos)
f.onFoo(foo);
}
public boolean methodThatTriggersBarAndChecksListeners()
{
Object bar = Boolean.TRUE;
for (Listeners.OnBar b : onBars)
if (!b.onBar(bar))
return false;
return true;
}
}
jako třeba že chci, aby Java měla v stdlib podporu pro události - ANO TO OPRAVDU CHCI, vždyť je naprosto elementární věc.
Tak elementární, že abyste to měl v C++, potřebujete Qt s vlastním preprocesorem? (Ano, vím, že to jde i bez preprocesoru (http://sigslot.sourceforge.net/), ale v STL/ISO C++ žádné události stejně nejsou.)
-
A co tohle, je to me mistrovske dilo, ctete prosim pozorne:
public interface IObserver<T> {
public void eventFired(T delegat);
}
public class Observable<T> {
Collection<IObserver> observers = new ArrayList<>();
public void add(IObserver listener) {
observers.add(listener);
}
public void emit(T delegat) {
for(IObserver<T> observer : observers) {
observer.eventFired(delegat);
}
}
}
public class HruskaDelegat {
String barvaHrusky;
public HruskaDelegat(String barvaHrusky) {
this.barvaHrusky = barvaHrusky;
}
}
public class Strom {
public final Observable<HruskaDelegat> fireSpadlaHruska = new Observable<>();
public void zatresStromem() {
fireSpadlaHruska.emit(new HruskaDelegat("cervena"));
}
}
public class RegistrujeEventu {
public static void main(String[] args) {
Strom strom = new Strom();
strom.fireSpadlaHruska.add(new IObserver<HruskaDelegat>() {
@Override public void eventFired(HruskaDelegat delegat) {
System.out.println( delegat.barvaHrusky );
}
});
strom.zatresStromem();
}
}
-
Jo mám tam takovou chybku, už jsem si ji opravil nebudu to updatovat. Jde tu prostě o ten princip, totiž že vystavím atribut jako public a že to pak přímočaře užívám.
-
Jo mám tam takovou chybku, už jsem si ji opravil nebudu to updatovat. Jde tu prostě o ten princip, totiž že vystavím atribut jako public a že to pak přímočaře užívám.
Veřejné atributy nejsou horší než veřejné gettery a settery.
-
A co tohle, je to me mistrovske dilo, ctete prosim pozorne:
to je skaredsi a horsi variant mojho riesenia.
* chcete videt zlatou prahu? pardon classcastexception?
strom.fireSpadlaHruska.add(new IObserver<JabkoDelegat>() {
@Override public void eventFired(JabkoDelegat delegat) {
System.out.println( delegat );
}
});
teda ste vobec nevyriesili problem s observable z java.util. (len si to myslite).
* dalej: verejne atributy v jave su "more than bad" practice. za to by vas aj v C# mlatili po prstoch
* prefixovat interfaces cez I je smrad z C#
-
* dalej: verejne atributy v jave su "more than bad" practice. za to by vas aj v C# mlatili po prstoch
Veřejné atributy se v C# používají naprosto běžně. Pouze se maskují za "vlastnosti".
-
A co tohle, je to me mistrovske dilo, ctete prosim pozorne:
to je skaredsi a horsi variant mojho riesenia.
* chcete videt zlatou prahu? pardon classcastexception?
strom.fireSpadlaHruska.add(new IObserver<JabkoDelegat>() {
@Override public void eventFired(JabkoDelegat delegat) {
System.out.println( delegat );
}
});
teda ste vobec nevyriesili problem s observable z java.util. (len si to myslite).
* dalej: verejne atributy v jave su "more than bad" practice. za to by vas aj v C# mlatili po prstoch
* prefixovat interfaces cez I je smrad z C#
Jj to je ta chybka kterou jsem si opravil, ted uz nemam cast exception a i Eclipse mi pekne ukazuje ze mi nesedi typ.
Teď ten public atribut. Nechápu co na tom může být v tomto případě špatného. Navíc je final, takže mi ho nikdo nepřepíše.
-
Jj to je ta chybka kterou jsem si opravil, ted uz nemam cast exception a i Eclipse mi pekne ukazuje ze mi nesedi typ.
ako ste to opravili?
Teď ten public atribut. Nechápu co na tom může být v tomto případě špatného. Navíc je final, takže mi ho nikdo nepřepíše.
v kazdom jazyku a kazdom projekte existuju konvencie
ked ich nedodrziavate ste prasa. bodka
dalsia vec: ak mate viacero eventov musite vyrabat viacero observable: napr fireSpadlaHruska.emit(new JabkoDelegat()); vam padne na kompilacii
dalsia vec: s generikami narabate velmi nevzdelane
jednoducho si myslite ze ste vymysleli lepsie riesenie ale nevymysleli
-
Opravil jsem to tak, ze jsem napsal:
public void Add(IObserver<T> observer) namísto (IObserver observer)
K tomu public atributu, tak bych napsal akorát getter no, čím bych tomu pomohl. Vy zrejme nechápete co tím sleduju, poučme se tedy společně z tohoto pokrokového jazyka:
public delegate void ChangedEventHandler(object sender, EventArgs e);
public event ChangedEventHandler Changed;
Changed(this, e); //takto sa vyvolává událost
Changed += new ChangedEventHandler(ListChanged); // a takto jednuše se registruje
https://msdn.microsoft.com/en-us/library/aa645739%28v=vs.71%29.aspx (https://msdn.microsoft.com/en-us/library/aa645739%28v=vs.71%29.aspx)
Takže ano, fireSpadlaHruska.emit(new JabkoDelegat()); se nezkompiluje, ale to je právě ten účel.
-
A kdyz se eventa jmenuje "SpadlaHruska", tak tam prece nebudu cpat Jabko :D :D :D to jenom vam na Slovensku je to jedno, protoze to hned seberete a date to kvasit. Ale kdyz pada hruska, tak tam musí být hruška :D
-
A kdyz se eventa jmenuje "SpadlaHruska", tak tam prece nebudu cpat Jabko :D :D :D to jenom vam na Slovensku je to jedno, protoze to hned seberete a date to kvasit. Ale kdyz pada hruska, tak tam musí být hruška :D
Když padá hruška, tak může spadnout do sudu ovoce - není nutné, aby to byl sud hrušek.
-
A kdyz se eventa jmenuje "SpadlaHruska", tak tam prece nebudu cpat Jabko :D :D :D to jenom vam na Slovensku je to jedno, protoze to hned seberete a date to kvasit. Ale kdyz pada hruska, tak tam musí být hruška :D
Na Moravě to děláme taky tak :)
-
A kdyz se eventa jmenuje "SpadlaHruska", tak tam prece nebudu cpat Jabko :D :D :D to jenom vam na Slovensku je to jedno, protoze to hned seberete a date to kvasit. Ale kdyz pada hruska, tak tam musí být hruška :D
Když padá hruška, tak může spadnout do sudu ovoce - není nutné, aby to byl sud hrušek.
Že už z tvých příspěvků tak nějak vím o tvém hnidopichsmu, tak ti určitě vadí, že objekt třídy strom informuje o tom, že padá hruška, což nemůže vědět. Takže tipuju že kdyby se eventa jmenovala "utrhlaSeMiHruska" tak už by se ti to líbilo.
-
Když padá hruška, tak může spadnout do sudu ovoce - není nutné, aby to byl sud hrušek.
Že už z tvých příspěvků tak nějak vím o tvém hnidopichsmu, tak ti určitě vadí, že objekt třídy strom informuje o tom, že padá hruška, což nemůže vědět. Takže tipuju že kdyby se eventa jmenovala "utrhlaSeMiHruska" tak už by se ti to líbilo.
Je to spíš ukázka možnosti využití polymorfismu, na který se často zapomíná. I když v Javě hodíš hrušku (objekt) do sudu s ovocem (kolekce), tak přesto neztrácí vlastnosti hrušky - nevoláš metody ovoce, ale hrušky.
-
Nicméně teprve teď když se učím Javu začínám zjišťovat, že vůbec neumím OOP. A teď je otázka, jestli to je dobře nebo špatně, pro Javu, protože v .NETech mě to tolik nepřišlo.
-
Nicméně teprve teď když se učím Javu začínám zjišťovat, že vůbec neumím OOP. A teď je otázka, jestli to je dobře nebo špatně, pro Javu, protože v .NETech mě to tolik nepřišlo.
OOP je v Javě dost zkriplené.
-
Nicméně teprve teď když se učím Javu začínám zjišťovat, že vůbec neumím OOP. A teď je otázka, jestli to je dobře nebo špatně, pro Javu, protože v .NETech mě to tolik nepřišlo.
Pro javu z toho nevyplyva vubec nic. Je dobre nebo spatne pro finstinu, ze z ni nerozumim ani slovo?
-
Nicméně teprve teď když se učím Javu začínám zjišťovat, že vůbec neumím OOP. A teď je otázka, jestli to je dobře nebo špatně, pro Javu, protože v .NETech mě to tolik nepřišlo.
Pro javu z toho nevyplyva vubec nic. Je dobre nebo spatne pro finstinu, ze z ni nerozumim ani slovo?
A co takhle spíše pro čínštinu?
-
Jako zkouším se zorientovat teď v netty. V tom se prostě nedá pořádně vyznat. To je OOP peklo. Měl by vzniknout nový termín: OOP-DesignPatterns-Hell a jako typicého představitele na wikipediích zmiňovat Javu. Funkce je tam ztracena v abstraktních třídách a rozhraních a asi by to k tomu vyloženě chtělo mít mapu vytisknutou na A1 a pověšenou na zdi.
-
Pracoval jsem už na rojektu většího rozsahu, vyvíjený od roku 2005 v Javě 1.5, byla to třívrstvá architektura. A neměl jsem v tom takový guláš jako v tom Netty, a to si nemyslím, že Netty vykonává složitější funkci. Ono rozdíl bude v tom, že ten projekt psal normální kluk, co tehdá dokončil VŠ, a byl to takový jeden z jeho prvních projektů, takže používal selské konstrukce. Nikde nepoužívá nějakou husto-krutou promyšlenou abstraktní kompoziční architekturu, takže všechno mělo tak nějak hlavu a patu, tipnul bych si že tam nebyla použita jediná abstraktní třída, eventy byly ten klasický javovský Observer-Observable s následným parsováním.
-
Už jste přišel na to, že vůbec neumíte OOP – je zajímavé, že vám to ale nebrání kritizovat z pohledu OOP kde co. Mimochodem, u Netty je nejdůležitější efektivita běhu výsledného programu a to, aby to správně (a efektivně) využíval i programátor, který nezná detaily síťové komunikace, její implementace v Javě a nemusí řešit detaily vícevláknového programování. Je to jako kdybyste OOP C++ posuzoval podle aplikace, která pro optimalizaci používá části napsané v assembleru…
-
A kdyz se eventa jmenuje "SpadlaHruska", tak tam prece nebudu cpat Jabko
vy ste hovorili ze mate 20 eventov. to znamena ze budete mat 20 public premennych a ste v spore sam so sebou
-
V mém ročníku na vš bylo takových 100 lidí, ale na jedné ruce bych spočítal ty, kteřížto jsou Javisti, vč. mě. Javu nikdo nechce dělat. Jo, z vedlejší univerzity, tam je javistů dost. Víš proč? Protože tam C# ani nemají, nikdy ho nezažili. U nás, kdo zažil C#, je pro něj Java shit. Naštěstí já jsem hrdý člověk a rád si dělám věci těžší, tak je ze mě Javista :D a to ti řeknu rovnou, že C#je tak o dvě třídy dál než Java, ale já bych nerad pracoval pro Microsoft, obzvlášť ne po tom, kam došly W10.
A toto srovnání děláš jako člověk, co si v rámci asi hodně krátkého času vyzkoušel jen tyto dva jazyky, které jsou s ohledem na zcela jiná paradigmata použitá jinde vlastně skoro totožné?
-
A toto srovnání děláš jako člověk, co si v rámci asi hodně krátkého času vyzkoušel jen tyto dva jazyky, které jsou s ohledem na zcela jiná paradigmata použitá jinde vlastně skoro totožné?
O totožnosti se moc mluvit nedá. C# víc vede ke strukturovanému programování, Java zase k objektovému. To jsou různá paradigmata, která způsobují potíže při přechodu mezi těmito jazyky.
-
A toto srovnání děláš jako člověk, co si v rámci asi hodně krátkého času vyzkoušel jen tyto dva jazyky, které jsou s ohledem na zcela jiná paradigmata použitá jinde vlastně skoro totožné?
O totožnosti se moc mluvit nedá. C# víc vede ke strukturovanému programování, Java zase k objektovému. To jsou různá paradigmata, která způsobují potíže při přechodu mezi těmito jazyky.
Delal jsem i ve Forthu, assemblerech, Lispu, na skolach do nas tlacili Prolog a Haskell - _toto_ jsou zcela odlisna paradigmata, z tohoto uhlu je C# a Java skoro totez (a naschval, je to tak navrzeno, aby na ne mohla prechazet majorita v ID). Jestli v Jave jsou lambdy az od osmicky, C# ma syntakticky cukr pro pristup k atributum atd., to jsou docela marginalni veci.
-
Jestli v Jave jsou lambdy az od osmicky, C# ma syntakticky cukr pro pristup k atributum atd., to jsou docela marginalni veci.
Jsou to marginální věci, ale umetají cestičku a vedou vývojáře určitým směrem. Objektově se dá programovat i v assembleru a imperativně v Javě. Jenom to ani v jednom případě není to "pravé ořechové".
Přístup k atributům degraduje OOP.
-
V mém ročníku na vš bylo takových 100 lidí, ale na jedné ruce bych spočítal ty, kteřížto jsou Javisti, vč. mě. Javu nikdo nechce dělat. Jo, z vedlejší univerzity, tam je javistů dost. Víš proč? Protože tam C# ani nemají, nikdy ho nezažili. U nás, kdo zažil C#, je pro něj Java shit. Naštěstí já jsem hrdý člověk a rád si dělám věci těžší, tak je ze mě Javista :D a to ti řeknu rovnou, že C#je tak o dvě třídy dál než Java, ale já bych nerad pracoval pro Microsoft, obzvlášť ne po tom, kam došly W10.
A toto srovnání děláš jako člověk, co si v rámci asi hodně krátkého času vyzkoušel jen tyto dva jazyky, které jsou s ohledem na zcela jiná paradigmata použitá jinde vlastně skoro totožné?
V mém ročníku na vš bylo takových 100 lidí, ale na jedné ruce bych spočítal ty, kteřížto jsou Javisti, vč. mě. Javu nikdo nechce dělat. Jo, z vedlejší univerzity, tam je javistů dost. Víš proč? Protože tam C# ani nemají, nikdy ho nezažili. U nás, kdo zažil C#, je pro něj Java shit. Naštěstí já jsem hrdý člověk a rád si dělám věci těžší, tak je ze mě Javista :D a to ti řeknu rovnou, že C#je tak o dvě třídy dál než Java, ale já bych nerad pracoval pro Microsoft, obzvlášť ne po tom, kam došly W10.
A toto srovnání děláš jako člověk, co si v rámci asi hodně krátkého času vyzkoušel jen tyto dva jazyky, které jsou s ohledem na zcela jiná paradigmata použitá jinde vlastně skoro totožné?
Omg jaká jiná paradigmata, mě zajímá normální programování, ne prolog-aspol-ismy. "Zcela jiná paradigmata použitá jinde" - lol kde? Tady, ať si máš čím vytřít zrak, ukaž mi to své jinde: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html , já nejsem pedagog na VŠ abych se mohl nimrat v blbinách a někdo mi za to platil.
Vážení jste blázní, jestli si myslíte, že po 20 letech vývoje Javy nepřišla největší a nejúspěšnější počítačová firma na světě, Microsoft, ve které se točí takové peníze, že by si o tom mohli v Sunu a Oraclu nechat zdát, s optimalizovanějším jazykem a platformou, která se poučila z chyb svých předchůců. Chcete to srovnávat s Javou. Kdo nedělal nikdy níc v .NET a ASP.NET, tak ať raději nic neříká, opravdu k tomu nemáte co říct... Hleďte si toho, že Java je zdarma, je pro ní spousta knihoven, může běžet bez problému i na Linux serveru, je nejrozšířenější, kdejaký Ind je javista, ale nesnažte se tu oponovat jak je to vlastně úplně na stejné úrovni jako .NET, ten je tak o třídu možná dvě výš: Jazyk je lepší, komfortnější, líp se to čte protože není tak ukecaný, nativní knihovna v .NET je úplná balada, dokumentace je o třídu lepší rovněž, je to všechno tak promyšlené, že se to krásně použivá, navíc všechno funguje out of box, knihovny jsou tak dobře napsané, že většinou hned víš, jak je používat, aniž bys četl dokumentaci, komunitní knihovny to opisují a jsou rovněž přehledné... no prostě je to úplně někde jinde. Firmy taky dost přechází na C#, ikdyž je placený, ale jim se to vyplatí, protože je ta všechno nádrherně funkční a to šetří čas. Na Javu to aby si ještě pro nové zaměstnance udělali 3 měsíční školení, jak něco v Javě vůbec vyvíjet.
-
Delal jsem i ve Forthu, assemblerech, Lispu, na skolach do nas tlacili Prolog a Haskell - _toto_ jsou zcela odlisna paradigmata, z tohoto uhlu je C# a Java skoro totez (a naschval, je to tak navrzeno, aby na ne mohla prechazet majorita v ID). Jestli v Jave jsou lambdy az od osmicky, C# ma syntakticky cukr pro pristup k atributum atd., to jsou docela marginalni veci.
No tak tady jde vidět že ty jsi v .NETech nikdy nic nedělal a vůbec je neznáš, ale budeš mi tady pindat.
-
Jestli v Jave jsou lambdy az od osmicky, C# ma syntakticky cukr pro pristup k atributum atd., to jsou docela marginalni veci.
Jsou to marginální věci, ale umetají cestičku a vedou vývojáře určitým směrem. Objektově se dá programovat i v assembleru a imperativně v Javě. Jenom to ani v jednom případě není to "pravé ořechové".
Přístup k atributům degraduje OOP.
souhlas
-
A toto srovnání děláš jako člověk, co si v rámci asi hodně krátkého času vyzkoušel jen tyto dva jazyky, které jsou s ohledem na zcela jiná paradigmata použitá jinde vlastně skoro totožné?
Omg jaká jiná paradigmata, mě zajímá normální programování, ne prolog-aspol-ismy. "Zcela jiná paradigmata použitá jinde" - lol kde? Tady, ať si máš čím vytřít zrak, ukaž mi to své jinde: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html , já nejsem pedagog na VŠ abych se mohl nimrat v blbinách a někdo mi za to platil.
Vážení jste blázní, jestli si myslíte, že po 20 letech vývoje Javy nepřišla největší a nejúspěšnější počítačová firma na světě, Microsoft, ve které se točí takové peníze, že by si o tom mohli v Sunu a Oraclu nechat zdát, s optimalizovanějším jazykem a platformou, která se poučila z chyb svých předchůců. Chcete to srovnávat s Javou. Kdo nedělal nikdy níc v .NET a ASP.NET, tak ať raději nic neříká, opravdu k tomu nemáte co říct... Hleďte si toho, že Java je zdarma, je pro ní spousta knihoven, může běžet bez problému i na Linux serveru, je nejrozšířenější, kdejaký Ind je javista, ale nesnažte se tu oponovat jak je to vlastně úplně na stejné úrovni jako .NET, ten je tak o třídu možná dvě výš: Jazyk je lepší, komfortnější, líp se to čte protože není tak ukecaný, nativní knihovna v .NET je úplná balada, dokumentace je o třídu lepší rovněž, je to všechno tak promyšlené, že se to krásně použivá, navíc všechno funguje out of box, knihovny jsou tak dobře napsané, že většinou hned víš, jak je používat, aniž bys četl dokumentaci, komunitní knihovny to opisují a jsou rovněž přehledné... no prostě je to úplně někde jinde. Firmy taky dost přechází na C#, ikdyž je placený, ale jim se to vyplatí, protože je ta všechno nádrherně funkční a to šetří čas. Na Javu to aby si ještě pro nové zaměstnance udělali 3 měsíční školení, jak něco v Javě vůbec vyvíjet.
[/quote]
ok takže odpověd na moji otázku je "ano" :-)
Jinak díky za tu charakteristiku Microsofu, pošlu to dál, i když mě na druhou stranu děsí, co z vás na té škole udělali. Prozradíš prosím, co to bylo za školu a jaká fakulta?
PS: zrovna ten Tiobe index ukazuje C# a Javu v jiném světle, než sám píšeš. Jde asi o to, že Java má větší ekosystém, důraz na kompatibitu (to není "díky" Oracle, ale navzdory jemu, díky Sunu, že to takto zařídil ještě když existoval), menší risk na ní něco začít stavět. Nehledej ani na C# ani na Javě žádnou magii, prostě mainstreamové jazyk se vším, co mainstream přináší.
-
ok takže odpověd na moji otázku je "ano" :-)
Jinak díky za tu charakteristiku Microsofu, pošlu to dál, i když mě na druhou stranu děsí, co z vás na té škole udělali. Prozradíš prosím, co to bylo za školu a jaká fakulta?
PS: zrovna ten Tiobe index ukazuje C# a Javu v jiném světle, než sám píšeš. Jde asi o to, že Java má větší ekosystém, důraz na kompatibitu (to není "díky" Oracle, ale navzdory jemu, díky Sunu, že to takto zařídil ještě když existoval), menší risk na ní něco začít stavět. Nehledej ani na C# ani na Javě žádnou magii, prostě mainstreamové jazyk se vším, co mainstream přináší.
Mě by naopak zajímalo, ne co jsi vystudoval ty, protože pindy od VŠ špekulantů co by si bez peněz státu na chleba nevydělali cpou do studentů leckde, ale čím se vlastně živíš. Tipnu si, že ty programátor nejsi.
Ty jsi totiž už od pohledu nikdo moc nedělal ani v Javě, ani v .NETech.
Ad rozšíření Javy: Java je tady cca 5x dýl než .NET, kdejaký archaický systém běží na Javě a musí se pořád správovat, kdejaký Ind je javista - jen pár procent populace na světě si může finančně dovolit .NET. Až někde bude v Indii, Číně nebo pakistánu bude vznikat nový projekt, tak to nebude v .NET, ale v Javě, a hádej proč. Čili tvoje reakce na Tiobe index přihrává mě, ne tobě.
-
Jazyk je lepší, komfortnější, líp se to čte protože není tak ukecaný
Bohužel C# je ukecaný podobně jako Java. F# je méně ukecaný. Prezentace C# Light (http://www.slideshare.net/ScottWlaschin/c-light) ukazuje, kolik balastu má C# (i Java).
nativní knihovna v .NET je úplná balada
Ano, třeba prasení s globálním stavem (např. SynchronizationContext.Current). Další problém jsou různé profily - může být docela obtížné napsat knihovnu, která funguje ve všech profilech. Dokumentace rovněž není úplně ideální.
Firmy taky dost přechází na C#, ikdyž je placený, ale jim se to vyplatí, protože je ta všechno nádrherně funkční a to šetří čas.
Není placený a vše ani není nádherně funkční.
-
Firmy taky dost přechází na C#,
citation needed
-
Firmy taky dost přechází na C#,
citation needed
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
V grafu povypínej vše kromě C# a VisualBasic.NET a máš důkaz. Zapni si javu a máš důkaz č. 2, kontinuálně klesající popularitu Java platformy. Je tam sice takový skok nahoru u javy, ale to je asi kvůli její nové verzi, za pár let to bude jen takový zub v jinak klesající populritě :)
Zamyšlení: teď si od Javy odečti všechny Indy, Pákistánce, Číňany a máš její popularitu na západě, kde bydlíme a máme to tu rádi. Pak se podívej na Jobs.cz a srovnej počty nabídek C# a Java a uvidíš, že je to cca 50:50.
-
Pak si ještě můžeš otevřít facebook, a jestli ho nemáš, tak ve jménu vědy a techniky si jej založ, a najdi si snad tu nejpočetnější javáckou skupinu "Java for Developers" která má 60tis. členů a můžeš začít počítat bělochy, moc jich tam není :D
-
Toto je velice pěkná indická Java programátorka, asi jsem se zamiloval :-*
https://www.facebook.com/profile.php?id=100010734106009
-
Zapni si javu a máš důkaz č. 2, kontinuálně klesající popularitu Java platformy.
java: +5.8%
c#: -1.34 %
můžeš začít počítat bělochy, moc jich tam není
amen
-
Prezentace C# Light (http://www.slideshare.net/ScottWlaschin/c-light) ukazuje, kolik balastu má C# (i Java).
Tahle prezentace mě kdysi inspirovala k tomu, že jsem si podobným způsobem odlehčil PHP a od té doby to používám.
-
v jave mate na hustu syntax groovy / scala / kotlin / ceylon
-
Pak si ještě můžeš otevřít facebook, a jestli ho nemáš, tak ve jménu vědy a techniky si jej založ, a najdi si snad tu nejpočetnější javáckou skupinu "Java for Developers" která má 60tis. členů a můžeš začít počítat bělochy, moc jich tam není :D
Kdo pro vývoj aplikací používá Facebook? Podívej se na nějaký odborný web, třeba StackOverflow, kde Java má o polovinu víc sledujících než C#. Nebo to Tiobe, kde Java soupeří akorát s C.
-
Pak si ještě můžeš otevřít facebook, a jestli ho nemáš, tak ve jménu vědy a techniky si jej založ, a najdi si snad tu nejpočetnější javáckou skupinu "Java for Developers" která má 60tis. členů a můžeš začít počítat bělochy, moc jich tam není :D
Kdo pro vývoj aplikací používá Facebook? Podívej se na nějaký odborný web, třeba StackOverflow, kde Java má o polovinu víc sledujících než C#. Nebo to Tiobe, kde Java soupeří akorát s C.
No mladí Indové asi docela jo :D
-
Pak si ještě můžeš otevřít facebook, a jestli ho nemáš, tak ve jménu vědy a techniky si jej založ, a najdi si snad tu nejpočetnější javáckou skupinu "Java for Developers" která má 60tis. členů a můžeš začít počítat bělochy, moc jich tam není :D
Kdo pro vývoj aplikací používá Facebook? Podívej se na nějaký odborný web, třeba StackOverflow, kde Java má o polovinu víc sledujících než C#. Nebo to Tiobe, kde Java soupeří akorát s C.
a co kecáš s tím stackOverflow, tady jasně vidím že je to fifty fifty Java vs C#
http://stackoverflow.com/tags
A to by ještě chtělo udělat větší průzkum jestli nevede zcela .NET, protože je tam třeba započítat další technologie které pod něj spadají a pokud jde o první stránku tagů, tak tam .NET dokonce zásadně vede. To sis pěkně naběhl teď a díky za tip :-)
-
Jo a ještě když čeknu Facebook, tak skupiny ASP.NET a C# jasně drtí javu a odpovídá to tomu, co jde pozorovat na stackOverflow :P
-
a co kecáš s tím stackOverflow, tady jasně vidím že je to fifty fifty Java vs C#
http://stackoverflow.com/tags
A to by ještě chtělo udělat větší průzkum jestli nevede zcela .NET, protože je tam třeba započítat další technologie které pod něj spadají a pokud jde o první stránku tagů, tak tam .NET dokonce zásadně vede. To sis pěkně naběhl teď a díky za tip :-)
To se díváš na počet otázek :) Když na ten tag najedeš, ukáže ti to, kolik lidí jej sleduje.
-
ok takže odpověd na moji otázku je "ano" :-)
Jinak díky za tu charakteristiku Microsofu, pošlu to dál, i když mě na druhou stranu děsí, co z vás na té škole udělali. Prozradíš prosím, co to bylo za školu a jaká fakulta?
PS: zrovna ten Tiobe index ukazuje C# a Javu v jiném světle, než sám píšeš. Jde asi o to, že Java má větší ekosystém, důraz na kompatibitu (to není "díky" Oracle, ale navzdory jemu, díky Sunu, že to takto zařídil ještě když existoval), menší risk na ní něco začít stavět. Nehledej ani na C# ani na Javě žádnou magii, prostě mainstreamové jazyk se vším, co mainstream přináší.
Mě by naopak zajímalo, ne co jsi vystudoval ty, protože pindy od VŠ špekulantů co by si bez peněz státu na chleba nevydělali cpou do studentů leckde, ale čím se vlastně živíš. Tipnu si, že ty programátor nejsi.
Ty jsi totiž už od pohledu nikdo moc nedělal ani v Javě, ani v .NETech.
Ad rozšíření Javy: Java je tady cca 5x dýl než .NET, kdejaký archaický systém běží na Javě a musí se pořád správovat, kdejaký Ind je javista - jen pár procent populace na světě si může finančně dovolit .NET. Až někde bude v Indii, Číně nebo pakistánu bude vznikat nový projekt, tak to nebude v .NET, ale v Javě, a hádej proč. Čili tvoje reakce na Tiobe index přihrává mě, ne tobě.
Od pohledu, zacinas me bavit :)
ok:
1) 20 let praxe v C(++), Java, prace na toolu co prevedl pomerne velkou aplikaci z C# do Javy (!!!!), neco malo (par desitek tisic radku) v ruznych assemblerech, hlavne pro DSP
2) stari Javy: 21 let, stari .NET: 13 let, tedy na to nepotrebuju VS abych vedel, ze 21 neni 5x13
S tim kdo si muze dovolit .NET to tedy vubec nechapu, jako ze nemaji na OEM Windows nebo jak?
-
... prace na toolu co prevedl pomerne velkou aplikaci z C# do Javy (!!!!), ...
S takovými nástroji mám neblahou zkušenost, že obvykle ten program prodlouží, místo aby ho zkrátily. Ovšem podstatné je, že to splnilo účel.
-
Od pohledu, zacinas me bavit :)
ok:
1) 20 let praxe v C(++), Java, prace na toolu co prevedl pomerne velkou aplikaci z C# do Javy (!!!!), neco malo (par desitek tisic radku) v ruznych assemblerech, hlavne pro DSP
2) stari Javy: 21 let, stari .NET: 13 let, tedy na to nepotrebuju VS abych vedel, ze 21 neni 5x13
S tim kdo si muze dovolit .NET to tedy vubec nechapu, jako ze nemaji na OEM Windows nebo jak?
Ale to se nepočítá, že jsi 20 let zametal podlahu programátorům v kanceláři, víš o tom doufám :DD Protože jinak nevím, jak by jsi mohl napsat, že .NET a Java jsou skoro stejné. To je fuk, že jsi dělal na něčem, co převedlo něco z C# do Javy, to totiž ještě neznamená, že znáš .NET, že sis někdy vyzkoušel udělat třívrstvou architekturu v .NET a ve J2EE, že znáš .NET knihovny a četl sis někdy k nějaké dokumentaci. To skrátka neznamená, že ty 2 platformy umíš porovnat.
-
... prace na toolu co prevedl pomerne velkou aplikaci z C# do Javy (!!!!), ...
S takovými nástroji mám neblahou zkušenost, že obvykle ten program prodlouží, místo aby ho zkrátily. Ovšem podstatné je, že to splnilo účel.
Vim, ale ono to jinak neslo - http://lpeer.blogspot.cz/2010/04/switching-from-c-to-java.html
-
Od pohledu, zacinas me bavit :)
ok:
1) 20 let praxe v C(++), Java, prace na toolu co prevedl pomerne velkou aplikaci z C# do Javy (!!!!), neco malo (par desitek tisic radku) v ruznych assemblerech, hlavne pro DSP
2) stari Javy: 21 let, stari .NET: 13 let, tedy na to nepotrebuju VS abych vedel, ze 21 neni 5x13
S tim kdo si muze dovolit .NET to tedy vubec nechapu, jako ze nemaji na OEM Windows nebo jak?
Ale to se nepočítá, že jsi 20 let zametal podlahu programátorům v kanceláři, víš o tom doufám :DD Protože jinak nevím, jak by jsi mohl napsat, že .NET a Java jsou skoro stejné. To je fuk, že jsi dělal na něčem, co převedlo něco z C# do Javy, to totiž ještě neznamená, že znáš .NET, že sis někdy vyzkoušel udělat třívrstvou architekturu v .NET a ve J2EE, že znáš .NET knihovny a četl sis někdy k nějaké dokumentaci. To skrátka neznamená, že ty 2 platformy umíš porovnat.
Ano, Java a .NET (presneji: Java a C#) jsou skoro stejne. Pokud mas pocit, ze se nejak radikalne lisi, tak jsi nepoznal svet a za domaci ukol si nastuduj trebas Haskell, Prolog a assembler.
-
Ale to se nepočítá, že jsi 20 let zametal podlahu programátorům v kanceláři, víš o tom doufám :DD Protože jinak nevím, jak by jsi mohl napsat, že .NET a Java jsou skoro stejné. To je fuk, že jsi dělal na něčem, co převedlo něco z C# do Javy, to totiž ještě neznamená, že znáš .NET, že sis někdy vyzkoušel udělat třívrstvou architekturu v .NET a ve J2EE, že znáš .NET knihovny a četl sis někdy k nějaké dokumentaci. To skrátka neznamená, že ty 2 platformy umíš porovnat.
No tak hlavně že to umí porovnat někdo, kdo se v Javě učí pár týdnů a v .NETu evidentně taky dělal jenom chvíli ;)
-
Ok ok, už mlčím, už nic neříkám rači. Prohrál jsem. Ale stejně měli dát do Javy eventy.
-
Vidím, že Java má tuto fanstránku :DD
http://whyjavasucks.com/?page=13
Java Updater:
http://i.imgur.com/UvIQLeE.jpg
-
Ok ok, už mlčím, už nic neříkám rači. Prohrál jsem. Ale stejně měli dát do Javy eventy.
(http://www.funintel.com/contents/member/xconfig/photos/NeverGiveUp-cf8470.jpg)
-
(http://www.quickmeme.com/img/58/58da71aa70835d82f576f40acdb3d692931364748ab47f405dfc0c9782795d90.jpg)
-
Takto vypadá oracle dokumentace, to je počtení!!! Jsou to kluci šikovní, vytvořit takovou pastvu pro oči, to není jen tak.
http://docs.oracle.com/javase/7/docs/technotes/guides/language/try-with-resources.html
-
Takto vypadá oracle dokumentace, to je počtení!!! Jsou to kluci šikovní, vytvořit takovou pastvu pro oči, to není jen tak.
http://docs.oracle.com/javase/7/docs/technotes/guides/language/try-with-resources.html
Už si ulevil? Cítíš se v pohodě? Nějaké novinky? Jak vypadá stolice? ;D
-
Takto vypadá oracle dokumentace, to je počtení!!! Jsou to kluci šikovní, vytvořit takovou pastvu pro oči, to není jen tak.
http://docs.oracle.com/javase/7/docs/technotes/guides/language/try-with-resources.html
.
Co je na tom špatně? Tedy jí firmu Oracle vůbec nemusím, ale zrovna tato stránka je podle mě ok.
A vůbec, už to tady sleduji delší dobu - jsi dost nevyrovnaný, neslušný na lidi, co ti chtějí pomoci, teď jsi asi po pár dnech zjistil, že Java není další stříbrná kulka (to je objev! v IT běžné ne?), tak posíláš negativní info, nic jiného. Do teamu bych tě tedy nechtěl a dost lituji tvoje případné kolegy.
-
Co je na tom špatně? Tedy jí firmu Oracle vůbec nemusím, ale zrovna tato stránka je podle mě ok.
A vůbec, už to tady sleduji delší dobu - jsi dost nevyrovnaný, neslušný na lidi, co ti chtějí pomoci, teď jsi asi po pár dnech zjistil, že Java není další stříbrná kulka (to je objev! v IT běžné ne?), tak posíláš negativní info, nic jiného. Do teamu bych tě tedy nechtěl a dost lituji tvoje případné kolegy.
Třeba jsem tvůj kolega, a ani o tom nevíš. A jestli ti příjde webovka s článkem co má text jednoho kraje monitoru k druhému, sloužící jako dokumentace k nejrozšířenějšímu jazyku na světě, na stránkách korporace, která ho má ve správě, normální, tak já tvoje případné kolegy lituji taktéž. Tohle by dneska neudělalo ani úplné ucho, co se zrovna učí dělat webové stránky. Mohl bych pokračovat, vnucování Ask Toolbaru, kdejaká instalace sw od Oraclu je provázena chybovými hláškami, historie jejich produktu JDeveloper je rovněž dosti rozporuplná. Prostě jako Java no, vrána k vráně sedá a tak to je i zde, bohužel.
-
ps: sleduj jak má vypadat slušná úroveň: https://msdn.microsoft.com/en-us/library/bb397676.aspx
-
Prostě jako Java no, vrána k vráně sedá a tak to je i zde, bohužel.
Konečně vás chápu. Vy jste si myslel, že je Java nejhorší prostředí pro vývoj aplikací, tak jste si řekl, že to se k vám hodí. Vrána k vráně…
-
Ty si strateny pripad. Za to, ze si si vybral jazyk, ktory nema do syntaxe zamontovany kazdy modny hype my nemozeme. Vrana k vrane sada, takze si chod smradit na .netove forum. Alebo tam ta uz zabanovali?
-
ps: sleduj jak má vypadat slušná úroveň: https://msdn.microsoft.com/en-us/library/bb397676.aspx
Je v tom nějaký významný rozdíl? Každá dokumentace vypadá prostě jinak. Uživatelé microsoftích produktů jsou zvyklí na omalovánky, tak prostě dostali omalovánky. V Lynxu nebo e-čtečce zase vypadá dokumentace Javy mnohem lépe než dokumentace C#.
-
Kit mozes o tom light PHP napisat blog?
-
Kit mozes o tom light PHP napisat blog?
Práce s Vimem dnes už moc lidí nezajímá. Ten mi to překládá do full PHP.
-
Ty si strateny pripad. Za to, ze si si vybral jazyk, ktory nema do syntaxe zamontovany kazdy modny hype my nemozeme. Vrana k vrane sada, takze si chod smradit na .netove forum. Alebo tam ta uz zabanovali?
To je totiž přesně ono, co mě tk převelice motivuje se tu hádat, vy tady totiž nejste schopní říct "ok, není to zrovna moc dodělané", to se netýká jen Javy, ale i věcí okolo Linuxu. Vy něco, co zcela objektivně není příliš ok, vezmete, a místo aby jste přikynuli, že by to tak nemělo být a že to není úplně v pohodě, začnete pindat "není to žádný modný hype", a další kraviny. Mohla by se tady přes kopírák vézt diskuze o něčem podobném, třeba proč to a ono nefunguje v Linuxu, a vy místo abyste řekli, "prostě na tom dělají lidi zadara, tak tam vždycky budou větši či menší nedodělky a chyby, ale zase na druhou stranu je to open source a má to dle mého zase takové a makové přednosti", řeknete něco jako "tak si táhni na widle", "co chceš, když neumíš ani používat konzoli", a další kraviny. Prostě místo aby jste normálně řekli, že to či ono ty mouchy prostě má, tak vymýšlíte haldu řečí. To je mentalita asi jako říct spolubydlícimu "proč jsi mi v pokoji zase nezavřel dveře, když procházíš" a on místo toho, aby je začal zavírat, začne říkat "no já jsem byl zrovna zamyšlený a měl jsem myšlenky jinde, pochop to, sice jsem ti dveře nezavřel, ale mělo ty důvody byly takové a onaké a ono zase na druhou stranu, ber to tak, že ti tu proudí čerstvý vzduch a líp slyšíš někoho na chodbě, takže můžeš rozpoznat i zloděje, má to i své výhody, takže opravdu nevím, na co si stěžuješ".
-
Lenze ono to je dodelane, ale nie tak ako by si ty chcel. Ja nemam problem povedat, ze java ma muchy, ale su to ine veci. Tvoja predstava, ze je to delany zadara iba dokazuje, ze s tym mas prakticky 0 skusenosti.
-
..., vy tady totiž nejste schopní říct "ok, není to zrovna moc dodělané", to se netýká jen Javy, ale i věcí okolo Linuxu.
Když se něco vytkne Microsoftu, tak to prohlásí za standard a spravovat to nebude.
Nedodělky jsou všude, kam se podíváš. Žádná firma nedodává finálně vyladěný SW, protože to prostě nejde. Ber to tak jak to je, jinak se z toho zblázníš.
-
Tohle by dneska neudělalo ani úplné ucho, co se zrovna učí dělat webové stránky. Mohl bych pokračovat, vnucování Ask Toolbaru, kdejaká instalace sw od Oraclu je provázena chybovými hláškami
takze "java sux lebo tech guide ma zle css."
historie jejich produktu JDeveloper je rovněž dosti rozporuplná
wtf
-
Mám dotaz, určitě se zde najde někdo kdo bere sportovně naše spory a odpoví. Mějme klasickou implementaci vzoru observer, kde událost vyvolávám takto:
private void fireSpadlaHruska() {
for(StromObserver observer : observers) {
handler.spadlaHruska();
}
}
private void fireSpadloJabko() {
for(StromObserver observer : observers) {
handler.spadloJabko();
}
}
}
Tak by mě zajímalo, jestli je kompilátor pro Javu taková šikulka, že se za běhu aplikace nemusí jakoby spouštět zcela prázdná metoda SpadloJabko() u nějakého observera, který na ní nijak nereaguje. Nebo se snad stane za běhu to, že skutečně dojde k sérii příkazů ve snaze spustit metodu, ve které nic není? (např observer Pepa chce vědět jen o pádu jabka a nezajímají ho hrušky. Třeba debugger by si do té metody vlezl.
-
Mám dotaz, určitě se zde najde někdo kdo bere sportovně naše spory a odpoví. Mějme klasickou implementaci vzoru observer, kde událost vyvolávám takto:
private void fireSpadlaHruska() {
for(StromObserver observer : observers) {
handler.spadlaHruska();
}
}
private void fireSpadloJabko() {
for(StromObserver observer : observers) {
handler.spadloJabko();
}
}
}
Tak by mě zajímalo, jestli je kompilátor pro Javu taková šikulka, že se za běhu aplikace nemusí jakoby spouštět zcela prázdná metoda SpadloJabko() u nějakého observera, který na ní nijak nereaguje. Nebo se snad stane za běhu to, že skutečně dojde k sérii příkazů ve snaze spustit metodu, ve které nic není? (např observer Pepa chce vědět jen o pádu jabka a nezajímají ho hrušky. Třeba debugger by si do té metody vlezl.
Krátká odpověď:
1) překladač do bajtkódu to nedělá, protože vlastně (skoro) každá metoda je virtuální, takže použije invokevirtual a dopředu neví, jak to dopadne (můžeš tam v runtime podstrčit třeba jiný class soubor atd.)
2) JIT překladač to dělá, pokud po X bězích (v závislosti na nastavení JVM) zjistí, že to skutečně nemá cenu, volat kód jen s RET. Lze zjistit přes -XX:+PrintCompilation
Osobně bych to asi neřešil, ten overhead je malý a JIT to opraví až po nějaké době.
-
Mám dotaz, určitě se zde najde někdo kdo bere sportovně naše spory a odpoví. Mějme klasickou implementaci vzoru observer, kde událost vyvolávám takto:
private void fireSpadlaHruska() {
for(StromObserver observer : observers) {
handler.spadlaHruska();
}
}
private void fireSpadloJabko() {
for(StromObserver observer : observers) {
handler.spadloJabko();
}
}
}
Tak by mě zajímalo, jestli je kompilátor pro Javu taková šikulka, že se za běhu aplikace nemusí jakoby spouštět zcela prázdná metoda SpadloJabko() u nějakého observera, který na ní nijak nereaguje. Nebo se snad stane za běhu to, že skutečně dojde k sérii příkazů ve snaze spustit metodu, ve které nic není? (např observer Pepa chce vědět jen o pádu jabka a nezajímají ho hrušky. Třeba debugger by si do té metody vlezl.
Mozna uz by bylo nacase, abyste zacal javu studovat a ne jen nadavat a ptat se na kazdou kravinu ve forech.
Java i JVM je open source tady jsou zdrojaky http://openjdk.java.net/ Porad tvrdite jak je .net a jazyk c lepsi, tak predpokladam, ze v C umite aspon cist zdrojove kody.
Tvrdite jak je Java spatna (mel byste rozlysovat Java a JVM), tak predpokladam, ze znate do detailu runtime .NET, popripade jine platformy, nebo jste si dokonce vlastni prekladac napsal.
Na zaklade tohoto bystem mel byt schopen si odpovedi najit sam ve zdrojovych kodech JVM a pochopit co je to JIT a jak funguje, pokud jste se s tim na jinych platformach nesetkal, misto lacineho placani, ze je Java pomala.
-
Java i JVM je open source tady jsou zdrojaky http://openjdk.java.net/
To je jen jedna implementace Javy a JVM. Ja pouzival IBM JDK a bezelo to pocitove o mnoho svizneji nez Sun Java; JRockit dle nekoho taky vyhraval. A OpenJDK bylo daleko za Sun implementaci.
Nevim, jak je to ted, ale byt vami, vyzkousel bych vice implementaci.
-
A OpenJDK bylo daleko za Sun implementaci.
OpenJDK vzniklo zveřejněním těch částí Sun implementace, které bylo možné z hlediska licencí zveřejnit. Takže obecně bych o rozdílech v rychlosti pochyboval, když je to to samé.
-
Tak by mě zajímalo, jestli je kompilátor pro Javu taková šikulka
Java jako jazyk je prakticky assembler pro byte kód. Kompilátor pro Javu tedy záměrně prakticky nic neoptimalizuje. Optimalizuje až JVM, protože má pro optimalizaci mnohem více informací, než kompilátor.
-
A OpenJDK bylo daleko za Sun implementaci.
OpenJDK vzniklo zveřejněním těch částí Sun implementace, které bylo možné z hlediska licencí zveřejnit. Takže obecně bych o rozdílech v rychlosti pochyboval, když je to to samé.
Presne tak. Licence je GPL with classpath exception. Oracle JDK vychazi z OpenJDK, takze musi dodrzovat tuto licenci.
JRockit se postupne merguje do jdk (https://blogs.oracle.com/henrik/entry/oracles_jvm_strategy) a jeji placene casti zacinaji byt placene pluginy do Oracle JDK. Napriklad Flight Recorder http://docs.oracle.com/cd/E15289_01/doc.40/e15070/introduction.htm http://www.oracle.com/technetwork/java/javaseproducts/mission-control/java-mission-control-1998576.html
IBM nevim, myslel jsem si, ze zije uz jen mainframe verze, ale podle nabidky na stazeni tam je verze i pro linux. Pouzivate IBM javu v produkci na Intel strojich? Nemam dostatek informaci a C4BS veli zustan u Oracle/OpenJDK, vsak IBM se taky prida a bude to delat jako Oracle
Podle wikipedie uz tam dokonce jsou minimalne vyuzivaji knihovny a maji svoje jvm :) https://en.wikipedia.org/wiki/OpenJDK#Collaboration_with_IBM.2C_Apple.2C_and_SAP
Zapomel jste na Azul. To je asi jedina alternativa o ktere bych uvazoval v pripade, ze mi z jakehokoliv duvodu Oracle/OpenJDK nestaci. Pouzivate nekdo?
Ad openJDK,
jsem strasne moc rad za to ze existuje. Oracle java ma jeden velky problem v renderovani obrazku se zapnutym antialiasingem. Ductus implementace je optimalizovana pro renderovani jednoho obrazku a ne pro paralelni renderovani. V pripade, ze chci renderovat vic nez jeden, tak je to velmi ale velmi pomale. Tato cast nemohla byt uvolnena z licencnich duvodu. Vznikl projek https://github.com/bourgesl/marlin-renderer/wiki/How-to-use , ktery je(byl?) pomalejsi, ale v pripade 10 requestu uz byl nasobne rychlejsi. To se nam zrovna v GIS systemech hodi vic. Diskuze o rychlosti je opravdu velmi relativni :).
-
Tak by mě zajímalo, jestli je kompilátor pro Javu taková šikulka
Java jako jazyk je prakticky assembler pro byte kód. Kompilátor pro Javu tedy záměrně prakticky nic neoptimalizuje. Optimalizuje až JVM, protože má pro optimalizaci mnohem více informací, než kompilátor.
Ale zase má na ně mnohem méně času.
-
Ale zase má na ně mnohem méně času.
Myslím, že ty týdny, kdy běží aplikace na serveru (což je dnes nejtypičtější použití Javy), jsou dost času…
-
No tak ja som si robil nejake testy a starsi server jvm sa bez tiered compilation pri niektorych sluzbach a celkovom pocte requestov k tym super mega optimalizaciam snad ani nedostal. A kto uz len robi preheating na celu apku? Netvrdim, ze to je problem, skor je to taka vec co sa mi nepaci a jeden z dovodov, preco sa zaujimam o golang (druhy je, ze golang sa ovela viac hodi na male projekty, nie je to pamatozrut).
-
No tak ja som si robil nejake testy a starsi server jvm sa bez tiered compilation pri niektorych sluzbach a celkovom pocte requestov k tym super mega optimalizaciam snad ani nedostal. A kto uz len robi preheating na celu apku? Netvrdim, ze to je problem, skor je to taka vec co sa mi nepaci a jeden z dovodov, preco sa zaujimam o golang (druhy je, ze golang sa ovela viac hodi na male projekty, nie je to pamatozrut).
https://www.azul.com/products/zing/readynow-technology-for-zing/ jeste jsem nepotkal nikoho, kdo by si koupil jvmko od Azulu.
-
Ale zase má na ně mnohem méně času.
Myslím, že ty týdny, kdy běží aplikace na serveru (což je dnes nejtypičtější použití Javy), jsou dost času…
Toto byla pravda, dokud jsme nenasadili cluster. Plan je o vikendu a off peak nechat bezet jen dva stroje.
Takze toto zacne byt casem trochu problem.
https://www.azul.com/products/zing/readynow-technology-for-zing/
to muze spravit, ale na to zatim nedostanu penize a taky mi vadi, ze s tim delaji tolik tajnosti a nemuzu si jejich jvm osahat v dev fazi.
-
No tak ja som si robil nejake testy a starsi server jvm sa bez tiered compilation pri niektorych sluzbach a celkovom pocte requestov k tym super mega optimalizaciam snad ani nedostal. A kto uz len robi preheating na celu apku? Netvrdim, ze to je problem, skor je to taka vec co sa mi nepaci a jeden z dovodov, preco sa zaujimam o golang (druhy je, ze golang sa ovela viac hodi na male projekty, nie je to pamatozrut).
Jo, Go je lepší volba, má mnohem lepší optimalizace a žádný dynamický runtime.
-
Jo, Go je lepší volba, má mnohem lepší optimalizace a žádný dynamický runtime.
Go nemá generika (kromě pár vestavěných generických typů). Kvůli tomu mi přijde Go prakticky nepoužitelné.
-
Jo, Go je lepší volba, má mnohem lepší optimalizace a žádný dynamický runtime.
Go nemá generika (kromě pár vestavěných generických typů). Kvůli tomu mi přijde Go prakticky nepoužitelné.
Ono je nemá by design.
-
Jo, Go je lepší volba, má mnohem lepší optimalizace a žádný dynamický runtime.
Go nemá generika (kromě pár vestavěných generických typů). Kvůli tomu mi přijde Go prakticky nepoužitelné.
Ono je nemá by design.
Coz neznamena, ze je to dobre. Jen ze je to umyslne.
-
Jo, Go je lepší volba, má mnohem lepší optimalizace a žádný dynamický runtime.
Go nemá generika (kromě pár vestavěných generických typů). Kvůli tomu mi přijde Go prakticky nepoužitelné.
Ono je nemá by design.
Coz neznamena, ze je to dobre. Jen ze je to umyslne.
Není to ani dobře ani špatně, C je použitelné i bez nich a stejně tak byla Java před 1.5 (zrovna v Javě jsou generika dodnes implementovaná debilně).
-
Není to ani dobře ani špatně, C je použitelné i bez nich a stejně tak byla Java před 1.5 (zrovna v Javě jsou generika dodnes implementovaná debilně).
Cecko je jazyk, kde (void *) vydavaji za prostredek datove abstrakce.
A Javu pred 1.5 jsem zazil dost dlouho. Uz bych se nevracel (cimz nerikam, ze implementace generik v 1.5+ je nejak oslniva. Ale je vyrazne lepsi nez zadna)
-
Není to ani dobře ani špatně, C je použitelné i bez nich a stejně tak byla Java před 1.5 (zrovna v Javě jsou generika dodnes implementovaná debilně).
Cecko je jazyk, kde (void *) vydavaji za prostredek datove abstrakce.
A Javu pred 1.5 jsem zazil dost dlouho. Uz bych se nevracel (cimz nerikam, ze implementace generik v 1.5+ je nejak oslniva. Ale je vyrazne lepsi nez zadna)
Go má zase interface{}, což bohatě stačí. Ani na void* není nic špatného, když se použije rozumně.
-
Není to ani dobře ani špatně, C je použitelné i bez nich a stejně tak byla Java před 1.5 (zrovna v Javě jsou generika dodnes implementovaná debilně).
Cecko je jazyk, kde (void *) vydavaji za prostredek datove abstrakce.
A Javu pred 1.5 jsem zazil dost dlouho. Uz bych se nevracel (cimz nerikam, ze implementace generik v 1.5+ je nejak oslniva. Ale je vyrazne lepsi nez zadna)
Go má zase interface{}, což bohatě stačí. Ani na void* není nic špatného, když se použije rozumně.
Očekával bych, že použití interface{} + reflexe bude minimálně stejně tak pomalé jako generika v Javě. Spíše to však bude pomalejší, neboť Go má strukturální podtypový polymorfismus, zatímco Java pouze nominální (zkontrolovat, že jeden typ je podtyp jiného, bude rychlejší v Javě).
Hlavní nevýhodou interface{} je však větší práce na straně programátora.
-
No a když už nejsme u těch event, tak co takhle eventy, neboli já mám raději "signály", implementovat za pomocí anotací, tak jak to má Spring framework? Je to dobré řešení?