Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: M&M Lentilky 11. 05. 2013, 10:21:23
-
Dlouho jsem vytvářel dynamické weby pomocí PHPčka, ale jakožto programátora jehož primárním jazykem je Java mě to táhlo k JavaEE. Z všechn stran jsem slyšel jak je to těžkopádný moloch, složitý atd atd, ale PHPko mi prostě nesedne. Proti gustu žádný dišputát ale vždycky jsem ho vnímal spíš jako špatný vtip než programovací jazyk. Tak mi to nedalo a ponořil jsem se do JavaEE. Zajímalo by mě, proč má takovou pověst, vždyť když potřebuju primitivní web s pár stránkama a dynamickýma fcema (patička, automat. generované menu apod.) tak si vystačím i s JSP a nikdo mě přece nenutí používat JSF, EJB a podobně, rozjedu to na nějakém light servlet containeru (a teď neřeším hostingy, ano, tam má PHPčko těžce navrh). No a pokud se mi projekt rozroste, nabízí mi Java EE plné možnosti jazyka Java a další jako ORM, JPA, EJB, REST a podobné. Nechci vyvolat flame ale tuhle otázku si dlouho pokládám, když v diskusích typu "Co místo PHPčka" vidím "zkus Python, RoR" ale ne Javu.
-
Java EE je populární, a to docela dost, jenom ne v naší kotlině. Ale já ji mám rád. <3
-
java neni cool :)
a protoze ji vsichni pouzivaji denne v praci a tak si radi odbehnou jinam a blogiskuji o tech odbezich jinam
-
celkove s JEE je problem prave s tema aplikacnimi servery. Ty maji obvykle ruzne implementace ruznych API a knihoven (do nejvetsi dokonalosti to dotahl IBM WAS, ktery ma v oblibe ssebou tahat zabugovane stare verze knihoven pro xml a jeste je prapodivne patchovat.). Mas problemy s classloaderem...
Dalsi problem s JEE je jeho pomaly neflexibilni vyvoj. Spring se vyviji dost rychle a reaguje na trh. Specifikace JEE je jedna vec, ale za jak dlouho od vydani specifikace JEE 6 byla implementovana do JBOS (letos?) do WAS (tam snad jeste neni), ...?
Dale donedavna byly vsechny aplikace silene molochy (jboss ale to trhnul asi). A AS musis vzdy v JEE pouzit. Pracovat bez bean nema smysl, a psat to pouze nad JSP a servletama neznamena psat v JEE to je SSE
-
celkove s JEE je problem prave s tema aplikacnimi servery. Ty maji obvykle ruzne implementace ruznych API a knihoven (do nejvetsi dokonalosti to dotahl IBM WAS, ktery ma v oblibe ssebou tahat zabugovane stare verze knihoven pro xml a jeste je prapodivne patchovat.). Mas problemy s classloaderem...
Dalsi problem s JEE je jeho pomaly neflexibilni vyvoj. Spring se vyviji dost rychle a reaguje na trh. Specifikace JEE je jedna vec, ale za jak dlouho od vydani specifikace JEE 6 byla implementovana do JBOS (letos?) do WAS (tam snad jeste neni), ...?
Dale donedavna byly vsechny aplikace silene molochy (jboss ale to trhnul asi). A AS musis vzdy v JEE pouzit. Pracovat bez bean nema smysl, a psat to pouze nad JSP a servletama neznamena psat v JEE to je SSE
A GlassFish jako referenční implementace JavaEE se nepoužívá v produkčním nasazení?
-
Najskor kvoli tomu, ze ked niekto povie java ee tak si kazdy predstavi hrube knihy, rozozrane aplikacne servery a dlhe restarty :). Ano, donedavna to tak bolo, ale vdaka hot patchingu a podobnym technologiam su tie restarty minimalne a ked som skusal jboss7 tak som chvilu myslel, ze sa to este nenastartovalo :).
-
Java EE je bomba :) Osobne utekam velmi daleko od vsetkych phpiek a pythonov a asi aj od ruby :)
Ano, u nas to nie je take popularne, pretoze tomu chyba uzivatelska zakladna. Kde tu je nejake forum o Java EE v cesko-slovenskom priestore? V PHP uz kodi kazdy BFU, Java EE ma dlhsiu krivku ucenia, nie je trivialne sklbit vsetko dokopy, EJB 3.1, CDI (aka Weld), Seam napr. REST, JAX-RS, WSDL, naucit sa adminovat EAP / JBoss, Maven (bez toho sa uz velmi nepohnes), JSF / JSP, JPA, JMS .... su tam toho tony, takze sam vidis co vsetko musis na seba nabalit a vediet, aby si sa v tom vyznal a nieco zmysluplne v tom spravil.
Vyhoda je ta, ze ked to raz nakodis (poriadne), poriadne to zdokumentujes a nesprasis navrh, tak ti je odmenou velmi dobra stabilita, odladenost, skalovatelnost a brutalna podpora na urovni middleware-u, mas to cele super duper otestovane ... proste mas za sebou velmi siroku podporu nastrojov a celu tu infrastrukturu za tym ... A to je to co pridava za ten nazov Javy to "EE" :) Ale krivka ucenia nie je taka strma ako inde a treba pri tom vydrzat ...
Ja verim ze cas Java EE este pride, EE6 vyzrera dost dobre, ked si k tomu este zoberies taky Forge alebo Arquillian tak to sa ti vyvija brutalne pohodlne :) Osobne nechapem odpor verejnosti k Java EE, hlavne ze vsetci phpkari vravia ze boze javisti, to su strasni lepici, sa pozrite na seba :D kormidlujete k jednemu frameworku k druhemu, podla nalady asi, sa to naucte raz a poriadne a nemusite riesit nic
-
Neblazni, ved nas prestanu dobre platit!
-
Zajímalo by mě, proč má takovou pověst...
V první řadě to není pravda. Java je hodně populární a rozšířená – jen se nesmíš ptát průměrného PHP bastlíře. Zeptej se ve firmě, kde se vytváří informační systémy (ne jen lepí weby).
A teď proč je Java(EE) nepopulární v určitých (okrajových) skupinách lidí:
- Je složitější než PHP, kde ti stačí jeden soubor. Musíš ji kompilovat. Jsou to banality, ale hodně lidí se nedostane dál než za „Hello world“ příklad, tudíž je to odradí.
- Na webu není tolik rozšířená, pořád je trochu náročnější/dražší sehnat webhosting s Javou než s PHP, klasický LAMP.
- Uživatel si kdysi zkusil spustit nějakou desktopovou aplikaci v Javě a startovalo to déle než aplikace v C/C++ → uživatel tedy nabyl dojmu, že Java je obecně pomalá.
- Někteří lidé mají pocit, že Java patří do velkých korporací, připadá jim příliš enterprise.
- Můžeš narazit i na fundovanější názor založený na zkušenosti a ne jen dojmologii: uživatel kdysi dávno pracoval se starými EJB a přišlo mu to hrozné. Ano, tehdy to bylo strašné, ale EJB 3.x jsou naopak velmi povedené. Dotyčný uživatel poněkud zaspal (tehdy byl jeho názor relevantní).
Podle tvého příspěvku to vypadá, že Javu znáš a líbí se ti. Tak neřeš, co o ní blábolí internetoví diskutéři a prostě pracuj na nějakém svém projektu, vybral sis dobrý nástroj, tak tě nemusí zajímat nějaké plky ostatních. Nebo se nech někde zaměstnat, dostaneš slušně zaplaceno a přijdeš do styku s důležitými systémy a zajímavými technologiemi.
-
- Na webu není tolik rozšířená, pořád je trochu náročnější/dražší sehnat webhosting s Javou než s PHP, klasický LAMP.
Len doplnim Frantu (za inak velmi kvalitny a objektivny nazor)
https://www.openshift.com/
http://en.wikipedia.org/wiki/OpenShift
Otazka hostingu (na nejaky cas a na prekonanie barier) vyriesena
-
Specifikace JEE je jedna vec, ale za jak dlouho od vydani specifikace JEE 6 byla implementovana do JBOS (letos?) do WAS (tam snad jeste neni), ...?
GlassFish to měl mnohem dřív.
psat to pouze nad JSP a servletama neznamena psat v JEE to je SSE
Servlety a JSP jsou součástí EE. (jiná věc je, že aby nějaký server byl „EE aplikačním serverem“, nestačí mu podporovat JSP a servlety)
-
A GlassFish jako referenční implementace JavaEE se nepoužívá v produkčním nasazení?
Nevim o zadnem zakaznikovi, ktery by mel v testu nebo produkci glassfish. Obvykle JBoss (je ~zadarmo a super), IBM WAS a budoucnost v EE vidim v Oracle WebLogic (dost se vyviji ekosystem okolo). Nevidim proc by oracle mel podporovat GlassFish, ze ktereho mu nejde ani koruna. Imho GF bude postupne utlumen a pouze jako reference a prijde neco jako WebLogic Expresss.
Jinek java je neoblibena, protoze potrebuje pametove resource ikdyz tam neni zadny klinet (architektura application scoped bean a podobne), narozdil od PHP, ktere kdyz nebezi, tak je "vyply". Kazde reseni ma sve vyhody a nevyhody. Hlavni nevyhodou pristupu javy je o hodne drazsi hosting jendoduchych aplikaci s malym pristupem uzivatelu. Coz je domena vetsiny zacatecniku v php...
Dalsi nevyhoda javy vidim v tom, ze programatora se trochu apson chovat a tak nejde tak rychle bastlit a prototypovat jako v ROO, pripadne PHP templatovachich frameworcich.
Osobne bych ti doporucil misto JEE zacit springem, ten se imho dnes pouziva casteji. Ja s nim pracuji denne, ale divam se co pribylo v JEE a jak to prevzal spring a vetsinou to uz mel pred rokem implementovane. Jedine co imho JEE bude prekonavat spring je Cloud, clustering SAS, na kterem melo byt v 6 docela zapracovano ze strany programatora (ale mozna to nakonec nebude tak horke, nevenuji se tomu tolik a mozna to spring ma implementovane, pripadne implementuje nebo ma substitut..). :)
-
- Na webu není tolik rozšířená, pořád je trochu náročnější/dražší sehnat webhosting s Javou než s PHP, klasický LAMP.
Len doplnim Frantu (za inak velmi kvalitny a objektivny nazor)
https://www.openshift.com/
http://en.wikipedia.org/wiki/OpenShift
Otazka hostingu (na nejaky cas a na prekonanie barier) vyriesena
A máte osobní zkušenosti s Openshiftem? Už jsem na něj koukal, zajímalo by mě jak je to např. s odezvou a rychlostí stránek.
-
Java je neoblíbená především u lidí, kteří "programují pro zábavu". Ten jazyk je sice čistý, ale programy v něm jsou pohádka na dobrou noc. V C# a v PHP např. můžu předat anonymní funkci jako argument do jiné funkce, v Javě musím vytvořit novou třídu (naštěstí stačí anonymní), která implementuje rozhraní IRunnable a tu teprve předat.
V C# můžu vzít kolekci a transformovat ji na jinou (kolekce.Select(...)), stejně tak v PHP (array_map(...)). V Javě to udělat nelze - je třeba vytvořit instanci nové kolekce, foreachem projít původní a přidávat prvek po prvku do té nové.
Místo použití .Net třídy ObservableCollection, která všem objektům, které o to mají zájem, dá pomocí eventů echo o tom, že se do ní přidaly / z ní odebraly prvky, musím v Javě řešit přes ObserverPattern. Srovnej třídu přímo v .Netu http://msdn.microsoft.com/cs-cz/library/ms668604.aspx a v ApacheCommons (která sice není součástí Javy, ale mnoho lidí ji bere jako "základní knihovnu", asi jako boost u C++) http://commons.apache.org/dormant/events/apidocs/org/apache/commons/events/observable/ObservableCollection.html
Atd... je toho hodně.
Takto se dá pokračovat. Zatímco jazyk PHP je prasárna a nic víc než zpropadená prasárna, rychlost vývoje je vyšší a u drobných aplikací máš menší paměťové nároky a kratší (= čitelnější a přehlednější) kód. Upřímně (přestože jsem full-time C# vývojář), PHP jsme na jeden projekt použili taky: Win8 Store aplikačka si potřebuje zjistit, odkud si stáhnout data a někam uložit adresu notifikačního kanálu. Nemá smysl kvůli tomu rozbíhat JavaEE server nebo platit za další Azure server, když pro těch pár tisíc uživatelů stačí malá databáze a něco, co může komunikovat přes REST "protokol". A strčit "ven" další linuxový server s PHP a deploynout projekt je téměř zadarmo. O Javu se musíš starat přece jenom víc. Výhody Javy se projeví až na větších projektech, které ale většina nadšenců nedělá, neb by jim to zabralo víkendy na několik let dopředu. A právě tito lidé (často to ani nejsou profi programátoři; mnozí z nich ani nepracují v IT a nemají IT vzdělání) jsou nejvíce vidět na diskusních fórech. Pro ně je ideální právě PHP a proto to vypadá, že JavaEE je neoblíbená a PHP velmi oblíbené, ačkoliv u profesionálů je pravdou přesný opak.
Pokud Ty se nechceš JavouEE živit, tak spíš než na JSP, které jsou hodně low-level (podobně jako čisté PHP bez frameworku), se můžeš zkusit zaměřit na nějaký high-level framework: mně na školní projekt kdysi celkem sedlo tohle: http://wicket.apache.org/ . Případně na Grails (http://www.grails.org/), což je framework pro Groovy. Groovy je druhý ze dvou oficiálních jazyků pro Java Virtual Machine (první je samozřejmě Java), jedná se o dynamický jazyk, ve kterém se mně osobně pracuje podobně (ne)příjemně jako v C#. Java je opravdu velmi rozvláčná a existuje jedna pravda, že programový kód je to místo, kde jsou chyby. Proto ho piš co nejméně, k čemuž Groovy pomůže. Případně můžeš zkusit jazyk jménem Clojure (taky běží na JVM) - získáš ještě přehlednější a kratší kód (byť si na ten jazyk musíš nejprve zvyknout, přeci jen je to odnož LISP-1) a webové framewroky jsou pro něj taky.
A přestože si na to mnoho vývojářů-nadšenců nepotrpí, tak pro Javu/Groovy lze sehnat lepší vývojová prostředí. NetBeans je dobrý základ, Eclipse má pluginy pro všechno (i když pohodlnost použití pro vývojáře pokulhává) a hlavně IntelliJ IDEA, za kterou se sice platí, ale je úplně the best. Nic takového pro PHP neseženeš a usnadní to hodně práce.
-
A máte osobní zkušenosti s Openshiftem? Už jsem na něj koukal, zajímalo by mě jak je to např. s odezvou a rychlostí stránek.
Nahral som tam len nejake primitivne stranky aby som si vyskusal cely ten princip ale myslim ze s odozvou nebude vobec problem. Sice to nemam nicim podlozene, ale mam pocit, ze existuju stranky ktorych primarna platforma je openshift a bezia bez problemov.
Samozrejme kriticke aplikacie tam (asi a zatial) nepatria.
Openshift je vyborny presne na ten ucel na aky potrebujete, rychly deploy bez problemov v cloude (nie len) java aplikacii.
Raz som tam skusal jednu aplikaciu vo frameworku Errai (http://www.jboss.org/errai) a ta aplikacia bola v openshifte. Islo o to, ze som mal v ruke telefon s androidom a ked som fyzicky naklanal obrazovku s www strankou na mobile (hore dole / doprava dolava) tak sa zaroven menil sklon nejakeho widgetu na www stranke na pocitaci predomnou na tej istej www stranke presne podla toho ako som hybal s mobilom. Viete si predstavit, ake "narocne" to je na response time aby mal z toho uzivatel nejaky "real time" zazitok.
Fungovalo to plynulo.
-
…
Dobře, že jsi zmínil alternativní jazyky, které se provozují nad JVM – to v podstatě odpovídá na výtky v prvních dvou odstavcích.
-
…
Dobře, že jsi zmínil alternativní jazyky, které se provozují nad JVM – to v podstatě odpovídá na výtky v prvních dvou odstavcích.
Ano, Javu jako jazyk používám jen když musím :)
Jinak když se v tomto threadu zmínil OpenShift, nevšiml jsem si zmínky o Cloud Foundry. Na mission-critical projekty to asi není, ale "hraní si" ... mají nativní podporu pro Grails (Groovy) a Play (Scala).
-
No a pokud se mi projekt rozroste, nabízí mi Java EE plné možnosti jazyka Java a další jako ORM, JPA, EJB, REST a podobné.
A bohužel možnosti jazyka Java nejsou zrovna velké (třeba ty technologie potřebujete, abyste obešel omezení Javy).
-
Koukám že jsem propásl příležitost napsat něco inteligentního, všichni mě předběhli.
Snad bych jen dodal, že Java EE obsahuje spoustu věcí (jen volně souvisejících) a v realitě stačí jen velmi malá množina. Vytváří se tím past, do které se často lidi chytí a vytvoří aplikaci zbytečně složitou (tzv. "moloch").
Pokusím se to formulovat jako aforismus:
Java EE se skládá ze tří částí: jedna obsahuje to co potřebuješ, druhá obsahuje to co nepotřebuješ a třetí obsahuje to o čem teprve po létech pochopíš k čemu by to mohlo být dobré.
-
No a pokud se mi projekt rozroste, nabízí mi Java EE plné možnosti jazyka Java a další jako ORM, JPA, EJB, REST a podobné.
A bohužel možnosti jazyka Java nejsou zrovna velké (třeba ty technologie potřebujete, abyste obešel omezení Javy).
Raději jednoduchý jazyk + knihovny než složitý všemocný jazyk.
-
JBoss (je ~zadarmo a super)
Kdo to myslí s provozováním aplikace jenom trochu vážně, tak si zaplatí komerční podporu. Nedokážu si dobře představit, že mě na nějakou interní chybu spadne aplikační server a já budu hledat jak chybu opravit někde na webu - můžete si být jist, že "komunitě" bude Vaše chyba na produkčním prostředí někde :)
Nevím, proč stále tolik lidí má dojem, že open-source je zdarma. Jsou oblasti, třeba kritické byznys aplikace (např. elektronické bankovnictví, ATM), kdy tohle neplatí.
-
JBoss (je ~zadarmo a super)
Kdo to myslí s provozováním aplikace jenom trochu vážně, tak si zaplatí komerční podporu. Nedokážu si dobře představit, že mě na nějakou interní chybu spadne aplikační server a já budu hledat jak chybu opravit někde na webu - můžete si být jist, že "komunitě" bude Vaše chyba na produkčním prostředí někde :)
Nevím, proč stále tolik lidí má dojem, že open-source je zdarma. Jsou oblasti, třeba kritické byznys aplikace (např. elektronické bankovnictví, ATM), kdy tohle neplatí.
A co ti brání si k tomu JBossu tu podporu zaplatit? Stejně tak si můžeš zaplatit podporu k GlassFishi a dalším aplikačním serverům. Nevím, proč stále tolik lidí má dojem, že svobodný software a komerční podpora jsou nějak v rozporu. Nejsou.
-
Raději jednoduchý jazyk + knihovny než složitý všemocný jazyk.
Zase extra jednoduchá Java také není.
Hlavní problém je, že Java je anti-modulární (=> nevhodná na programování větších systémů). Pro začátek bych z Javy odstranil dědičnost a "otevřel" třídy - tj. dovolil bych implementovat rozhraní pro třídu i mimo ni (lambda metody považuji za samozřejmost). Takový jazyk by byl IMO srovnatelně složitý.
-
Raději jednoduchý jazyk + knihovny než složitý všemocný jazyk.
Zase extra jednoduchá Java také není.
Hlavní problém je, že Java je anti-modulární (=> nevhodná na programování větších systémů).
Tohle nechápu. Neznám žádný modulární jazyk (jazyk, který poskládáš z modulů: např. v tomto programu nepotřebuju foreach, tak modul pro jeho syntaktickou podporu nyní vyhodím). Programové moduly Java podporuje, akorát jim říká "packages". Jinak moduly podporuje i čisté C nebo Turbo Pascal.
Pro začátek bych z Javy odstranil dědičnost a "otevřel" třídy - tj. dovolil bych implementovat rozhraní pro třídu i mimo ni (lambda metody považuji za samozřejmost). Takový jazyk by byl IMO srovnatelně složitý.
Jazyk by byl možná srovnatelně složitý, ale třídně založené objektově orientované programování JE o dědičnosti a o tom, že rozhraní je definováno mimo třídu. Pokud není, tak autor buď nechce, abys jej implementoval mimo jeho třídu, anebo je prase.
Java je objektový jazyk a v době jejího návrhu (první polovina 90. let; první produkční verze je AFAIK z 1995) se lamda výrazy běžně nepoužívaly (v C se používaly např. ukazatele na funkce). Kromě toho lamda výraz (anonymní funkce) je rys funkcionálního programování, ne objektového. Ano, taky bych uvítal, kdyby to tam bylo (když je to i ve SmallTalku ;-) ) společně s ekvivalentem .Netového LINQu, ale rozhodně to není možno nazvat slovem "samozřejmost".
-
V C# můžu vzít kolekci a transformovat ji na jinou (kolekce.Select(...)), stejně tak v PHP (array_map(...)).
What? Select ti vytvoří nový IEnumerable objekt (lazy) - s původní kolekci pochopitelně "netransformuje". Jediná dobrá věc (zato významná) na kolekcích v .NETu je LINQ. Jinak je to oproti Java Collection Framework bída, nemá množiny, stromy, etc.
Zase extra jednoduchá Java také není.
Na tohle se dá říct jen LOL.. srsly?? Jestli ti Java (samotný jazyk) příjde složitá, měl bys asi přesedlat na Baltíka.
Hlavní problém je, že Java je anti-modulární (=> nevhodná na programování větších systémů). Pro začátek bych z Javy odstranil dědičnost a "otevřel" třídy - tj. dovolil bych implementovat rozhraní pro třídu i mimo ni (lambda metody považuji za samozřejmost). Takový jazyk by byl IMO srovnatelně složitý.
Tohle je naprostá blbost.. Btw nadcházející Java 8 implementuje lambdy.
Ve zkratce - výhoda Javy v enterprise aplikacích je existující architektura. Např nHibernate je oproti Hibernate stále pozadu. Taky se na rozdíl od .NETu dá provozovat na všech platformách. Teamwork je díky Mavenu hračka. Spring spoustu věcí usnadňuje a má bezvadnou dokumentaci. A tak dále.. Java platform je hrozně rozsáhlá, napsat kdy je vhodné ji využít není na jeden post v diskuzi :)
-
Java je objektový jazyk a v době jejího návrhu (první polovina 90. let; první produkční verze je AFAIK z 1995) se lamda výrazy běžně nepoužívaly (v C se používaly např. ukazatele na funkce). Kromě toho lamda výraz (anonymní funkce) je rys funkcionálního programování, ne objektového. Ano, taky bych uvítal, kdyby to tam bylo (když je to i ve SmallTalku ;-) ) společně s ekvivalentem .Netového LINQu, ale rozhodně to není možno nazvat slovem "samozřejmost".
http://code.google.com/p/guava-libraries/wiki/FunctionalExplained
http://functionaljava.org/
To druhé je možná polomrtvé (i když úplnější), to první v pár projektech používám. Oproti nativní lambda je to o něco ukecanější, ale v zásadě možná o to čitelnější...
-
Jsem dlouholetý javista.
Příjde a mnou kamarád a potřebuje eshop a forum. Mám mu říct: super, uděláme EE řešení?
V posledním velkém (zahraničním) projektu, nás bylo asi 20 vývojářů + 30 testerů + 30 business lidí,
4 roky jsme vyvýjeli to, o čem jsme měl pořád pocit, že je stále horší, než kdyby se nainstaloval čistý Drupal.
Projekt za stovky milionů dolarů.
Já bych to PHP zas tolik nezatracoval.
Hlavně je tam obrovská studna implementovaných řešení a třeba ten Drupal považuji za hezký a čistý projekt - vyznám se v něm,
je chytře navržený, dají se dohledat detaily a chyby, podpora komunity je velká.
J(2)EE mi pořád připomíná trochu http://discuss.joelonsoftware.com/?joel.3.219431.12
Nemám například rád webservisy a jejich generování do tříd. Pokud se na něco pouze dotazuji, většinou mi i na tu webservisu stačí http get a parsovat xml odpověď a nemusím při každé změně WS překompilovávát kód ....
A poslední dobou si rád hraji se Scalou, proti Javě opravdu generuje inteligentně vyhlížející kód,
není tak blbuvzdorná, musí se na ní víc přemýšlet,
podle mne by omezila část prasáren, které ve velkých java projektech existují
(dlouho mám touhu vést si žebříček hrůzností co jsou lidi schopni napsat)
Z tohoto hlediska mě docela zajímá framework Play.
-
Minimir: Extension metoda Select je součástí LINQu. Mám-li být přesnější, jedná se o projekci (jednu kolekci zobrazí na jinou, samotnou relaci zobrazení udává funkce/lamda výraz, kterou do Select funkce předáš). DSL pro LINQ je jen syntaktický cukr nad extension metodami.
To, že se technicky vytváří nový objekt (kolekce), jehož třída implementuje IEnumerable a líně se tam přidávají prvky z původní kolekce aniž by byla původní dotčena, je pro můj původní příspěvek nepodstatné (a navíc je to "implementační detail", v ostatních jazycích ekvivalentní funkce vnitřně funguje jinak). Chtěl jsem poukázat na to, že v C# je podpora pro rozumnou práci s kolekcemi a jako příklad jsem vybral právě tuto funkci (v Haskellu se jí říká "map", v LISPu je to "mapcar" ... ale účel je stejný).
-
Java je objektový jazyk a v době jejího návrhu (první polovina 90. let; první produkční verze je AFAIK z 1995) se lamda výrazy běžně nepoužívaly (v C se používaly např. ukazatele na funkce). Kromě toho lamda výraz (anonymní funkce) je rys funkcionálního programování, ne objektového. Ano, taky bych uvítal, kdyby to tam bylo (když je to i ve SmallTalku ;-) ) společně s ekvivalentem .Netového LINQu, ale rozhodně to není možno nazvat slovem "samozřejmost".
http://code.google.com/p/guava-libraries/wiki/FunctionalExplained
http://functionaljava.org/
To druhé je možná polomrtvé (i když úplnější), to první v pár projektech používám. Oproti nativní lambda je to o něco ukecanější, ale v zásadě možná o to čitelnější...
Hezké, ale neřeší to ani mé přání, aby v Javě byla podpora pro lamda výrazy (neb toto není součást Javy a upřímně, moc rozšířené to také není), ani Radkovo vyjádření, že lambda výrazy v jazyku jsou samozřejmost.
V Javě v. 7 měly být, ale byly odloženy do Javy 8. Možná se jich po letech dočkáme.
-
Jsem dlouholetý javista.
...
A poslední dobou si rád hraji se Scalou, proti Javě opravdu generuje inteligentně vyhlížející kód,
není tak blbuvzdorná, musí se na ní víc přemýšlet,
podle mne by omezila část prasáren, které ve velkých java projektech existují
(dlouho mám touhu vést si žebříček hrůzností co jsou lidi schopni napsat)
Z tohoto hlediska mě docela zajímá framework Play.
Ten žebříček někdy zveřejni, myslím, že to bude velmi zajímavé čtení.
Se Scalou jsem si hrál chvíli také (zhruba před rokem), ale odradily mne od toho věci, které v ní někteří lidé vyprodukovali. Příklad - znáš knihovnu Dispatch? http://www.flotsam.nl/dispatch-periodic-table.html Chybové hlášky byly celkem šílené, doby kompilace projektu taky, stejně tak binární nekompatibilita mezi verzemi byl krapet problém a ve výčtu drobností, které znepříjemňují život, bych mohl pokračovat. Myslím, že ze Scaly se může stát plnohodnotný konkurent Javy, ale bude to ještě pár roků trvat.
-
Jazyk by byl možná srovnatelně složitý, ale třídně založené objektově orientované programování JE o dědičnosti a o tom, že rozhraní je definováno mimo třídu. Pokud není, tak autor buď nechce, abys jej implementoval mimo jeho třídu, anebo je prase.
Mluvím o implementaci rozhraní mimo třídu. Např. si vytvořím vlastní rozhraní Nakresli a budu chtít udělat implementaci pro třídu ze standardní knihovny. Můžu?
Dědičnost narušuje abstrakci a je těžké ji použít správně (komplikuje se kód). Dále dědičnost komplikuje definici jazyka. A navíc Java podtřídu chápe automaticky jako podtyp, ale podtřída nemusí být podtyp a naopak podtyp nemusí být podtřída.
Nevidím důvod, proč by jazyk nemohl mít třídy bez dědičnosti. Třídy by se mohly používat jen pro deklarace nominálního podtypového polymorfismu - např. bych mohl říci, že třída Kruh je podtyp třídy Tvar (kompilátor by zkontroloval, že to typy umožňují).
-
Minimir: Extension metoda Select je součástí LINQu. Mám-li být přesnější, jedná se o projekci (jednu kolekci zobrazí na jinou, samotnou relaci zobrazení udává funkce/lamda výraz, kterou do Select funkce předáš). DSL pro LINQ je jen syntaktický cukr nad extension metodami.
To, že se technicky vytváří nový objekt (kolekce), jehož třída implementuje IEnumerable a líně se tam přidávají prvky z původní kolekce aniž by byla původní dotčena, je pro můj původní příspěvek nepodstatné (a navíc je to "implementační detail", v ostatních jazycích ekvivalentní funkce vnitřně funguje jinak). Chtěl jsem poukázat na to, že v C# je podpora pro rozumnou práci s kolekcemi a jako příklad jsem vybral právě tuto funkci (v Haskellu se jí říká "map", v LISPu je to "mapcar" ... ale účel je stejný).
S tím, že je to v tomto kontextu jen implementační detail, nesouhlasím. Bavíme se snad o tom, jak ta metoda ve skutečnosti funguje a tys argumentoval tím, že v Javě při trasnformaci kolekce musíš vytvářet novou instanci. Jenže jinde taky. Takže je to podstatný detail.
Jinak zcela souhlasím s tím, že v .NETu se s kolekcemi pracuje skvěle. Jen mi tam spousta javových ekvivalentů chybí.
-
Hezké, ale neřeší to ani mé přání, aby v Javě byla podpora pro lamda výrazy (neb toto není součást Javy a upřímně, moc rozšířené to také není), ani Radkovo vyjádření, že lambda výrazy v jazyku jsou samozřejmost.
A to je *vazne* problem spravit si 1 interface a do svojich util metod si pripisat dve 3 riadkove funkcie? Ja to tak mam asi v kazdom projekte a pouzivam v pohode lambda funkcie (teda interface s 1 metodou, ktora sa aplikuje).
-
Mluvím o implementaci rozhraní mimo třídu. Např. si vytvořím vlastní rozhraní Nakresli a budu chtít udělat implementaci pro třídu ze standardní knihovny. Můžu?
Zdá se mi, že střílíš pojmy, které ti nejsou zcela jasné. Z tvého popisu mi vyvstávají dvě alternativy:
1. NakresliImpl extends <třída ze standardní knihovny> implements Nakresli
2. Extension metody - v Javě nejsou
Java podtřídu chápe automaticky jako podtyp, ale podtřída nemusí být podtyp a naopak podtyp nemusí být podtřída.
Vysvětli. V čem je třída, která dědí jinou "podtyp"?
-
Ve zkratce - výhoda Javy v enterprise aplikacích je existující architektura. Např nHibernate je oproti Hibernate stále pozadu. Taky se na rozdíl od .NETu dá provozovat na všech platformách. Teamwork je díky Mavenu hračka. Spring spoustu věcí usnadňuje a má bezvadnou dokumentaci. A tak dále.. Java platform je hrozně rozsáhlá, napsat kdy je vhodné ji využít není na jeden post v diskuzi :)
Rozsáhlost platformy J2EE je také nevýhoda. Mj. velké aplikace byly napsány i v Prologu, kde existuje minimum knihoven.
-
Rozsáhlost platformy J2EE je také nevýhoda. Mj. velké aplikace byly napsány i v Prologu, kde existuje minimum knihoven.
Hochu, ty jseš fakt troll. Řekneš, že existující architektura je nevýhoda, po tom co se tady porovnávala náročnost nové implementace a využití existujícího řešení? I'm outta here..
-
Minimir: Extension metoda Select je součástí LINQu. Mám-li být přesnější, jedná se o projekci (jednu kolekci zobrazí na jinou, samotnou relaci zobrazení udává funkce/lamda výraz, kterou do Select funkce předáš). DSL pro LINQ je jen syntaktický cukr nad extension metodami.
To, že se technicky vytváří nový objekt (kolekce), jehož třída implementuje IEnumerable a líně se tam přidávají prvky z původní kolekce aniž by byla původní dotčena, je pro můj původní příspěvek nepodstatné (a navíc je to "implementační detail", v ostatních jazycích ekvivalentní funkce vnitřně funguje jinak). Chtěl jsem poukázat na to, že v C# je podpora pro rozumnou práci s kolekcemi a jako příklad jsem vybral právě tuto funkci (v Haskellu se jí říká "map", v LISPu je to "mapcar" ... ale účel je stejný).
S tím, že je to v tomto kontextu jen implementační detail, nesouhlasím. Bavíme se snad o tom, jak ta metoda ve skutečnosti funguje a tys argumentoval tím, že v Javě při trasnformaci kolekce musíš vytvářet novou instanci. Jenže jinde taky. Takže je to podstatný detail.
Jinak zcela souhlasím s tím, že v .NETu se s kolekcemi pracuje skvěle. Jen mi tam spousta javových ekvivalentů chybí.
Ne. Smysl mého původního příspěvku je v tom, že instanci nové kolekce musíš vytvořit ručně. Příklad:
List<String> names = new ArrayList<String>(users.size());
for (User user : users) {
names.add(user.getName());
}
versus
var names = users.Select(user => user.Name).ToList();
nebo
(let [names (map :name users)])
-
1. NakresliImpl extends <třída ze standardní knihovny> implements Nakresli
A když je třída ze standardní knihovny final?
Když bych měl štěstí a nebyla final, udělal bych třídu NakresliImpl. Mezitím by Franta udělal knihovnu s rozhraním Řekni a třídou ŘekniImpl. Pak by přišel Pepa a chtěl by použít obě implementace obou rozhraní, co teď?
Java podtřídu chápe automaticky jako podtyp, ale podtřída nemusí být podtyp a naopak podtyp nemusí být podtřída.
Vysvětli. V čem je třída, která dědí jinou "podtyp"?
Např: Když v Javě Kruh podědí od Tvar, tak metodám, jenž mají parametr typu Tvar, mohu předat argument typu Kruh.
-
Rozsáhlost platformy J2EE je také nevýhoda. Mj. velké aplikace byly napsány i v Prologu, kde existuje minimum knihoven.
Hochu, ty jseš fakt troll. Řekneš, že existující architektura je nevýhoda, po tom co se tady porovnávala náročnost nové implementace a využití existujícího řešení? I'm outta here..
Zde je konkrétní příklad: Prolog and CHR in Finance (http://dtai.cs.kuleuven.be/CHR/files/Elston_SecuritEase.pdf). Všimněte si, s jak malým týmem začali. Kdyby to dělali celé v Javě (s nebo bez J2EE), tak IMO nemají šanci.
-
1. NakresliImpl extends <třída ze standardní knihovny> implements Nakresli
A když je třída ze standardní knihovny final?
Když bych měl štěstí a nebyla final, udělal bych třídu NakresliImpl. Mezitím by Franta udělal knihovnu s rozhraním Řekni a třídou ŘekniImpl. Pak by přišel Pepa a chtěl by použít obě implementace obou rozhraní, co teď?
Odpověď je jednoduchá: použij Scalu
http://www.artima.com/weblogs/viewpost.jsp?thread=179766
-
Odpověď je jednoduchá: použij Scalu
http://www.artima.com/weblogs/viewpost.jsp?thread=179766
Souhlasím (mj. v jiných jazycích se podobnému konceptu někdy říká typová třída, v Rustu to je trait).
Pokud už člověk použije Scalu, tak se IMO bude snažit používat knihovny pro Scalu, takže se bude vyhýbat J2EE.
-
Ten žebříček někdy zveřejni, myslím, že to bude velmi zajímavé čtení.
Se Scalou jsem si hrál chvíli také (zhruba před rokem), ale odradily mne od toho věci, které v ní někteří lidé vyprodukovali. Příklad - znáš knihovnu Dispatch? http://www.flotsam.nl/dispatch-periodic-table.html Chybové hlášky byly celkem šílené, doby kompilace projektu taky, stejně tak binární nekompatibilita mezi verzemi byl krapet problém a ve výčtu drobností, které znepříjemňují život, bych mohl pokračovat. Myslím, že ze Scaly se může stát plnohodnotný konkurent Javy, ale bude to ještě pár roků trvat.
Zatím můj all-time favorit z high-end enterprise projektu je asi tahle prasárna od nějakého indického kolegy (pozor, i indové umí být výborní programátoři, jen jich je poskrovnu) - čtení hodnot z CSV, samozřejmě copy&paste asi pro pět sloupečků:
if(csv.get("Name & last name of customer. For companies, ABN Identifier") != null) {
value = csv.get("Name & last name of customer. For companies, ABN Identifier")
} else if(csv.get(" Name & last name of customer. For companies, ABN Identifier ") != null) {
value = csv.get(" Name & last name of customer. For companies, ABN Identifier ")
}
Z čeho mi šla hlava kolem minulý týden, je launch.jnlp s referencí na weblogic.jar. Stahovat ke GUI aplikaci
celý weblogic server je prostě dobrej nápad :-).
-
Bol tu v suvislosti s JavaEE spominany GlassFish a mam pocit, ze nebol hodnoteny celkom pozitivne, skor ako nejaka referencna implementacia. Mam sa mu skor vyhnut, alebo je to OK riesenie?
-
S Glassfish nemám nejlepší zkušenosti. Jde možná ale spíš o věc způsobu vývoje. Není žádná podpora vydaných verzí, tím myslím oprava chyb, a že jich tam výrazných je. Prostě se to opraví až v nějakém dalším releasu, který je ale jiný.
U JBossu přece jen většinou aspoň nějaký ten "service pack" k dané verzi vydají.
Samozřejmě by to i tak chtělo placenou verzi, ale aspoň něco. Navíc mi přijde, že je na tom JBoss s těmi problémy lépe.
-
S Glassfish nemám nejlepší zkušenosti. Jde možná ale spíš o věc způsobu vývoje. Není žádná podpora vydaných verzí, tím myslím oprava chyb, a že jich tam výrazných je. Prostě se to opraví až v nějakém dalším releasu, který je ale jiný.
U JBossu přece jen většinou aspoň nějaký ten "service pack" k dané verzi vydají.
Samozřejmě by to i tak chtělo placenou verzi, ale aspoň něco. Navíc mi přijde, že je na tom JBoss s těmi problémy lépe.
Ta cena komercnej verzie je pre mna akceptovatelna. Kladiem asi amaterske otazky ale ako to presne funguje - to, ze je to "referencna implementacia" znamena, ze ak to napisem pre GlassFish, malo by to byt (aspon teoreticky) spustitelne aj pod tym JBoss (pripadne po nejakej rekompilacii)?
-
Ta cena komercnej verzie je pre mna akceptovatelna. Kladiem asi amaterske otazky ale ako to presne funguje - to, ze je to "referencna implementacia" znamena, ze ak to napisem pre GlassFish, malo by to byt (aspon teoreticky) spustitelne aj pod tym JBoss (pripadne po nejakej rekompilacii)?
NIe malo ale musi, ty neprogramujes voci nejakeku GlassFishu alebo potom voci JBoss-u, ty programujes v Java EE a to je vsetko co ta musi trapit, od toho sa to vola referencna implementacia, ze mozes vymenit aplikacny server a musi to fungovat. Inak by to nebola referencna implementacia. Ked oba servery implementuju nieco podla standardu, ako by bolo potom mozne, ze ked spustis dva projekty na kazdom z nich, tak na jednom nepojde a na druhom ano? Potom asi jeden z nich neimplementuje podla referencie ...
-
Ta cena komercnej verzie je pre mna akceptovatelna. Kladiem asi amaterske otazky ale ako to presne funguje - to, ze je to "referencna implementacia" znamena, ze ak to napisem pre GlassFish, malo by to byt (aspon teoreticky) spustitelne aj pod tym JBoss (pripadne po nejakej rekompilacii)?
NIe malo ale musi, ty neprogramujes voci nejakeku GlassFishu alebo potom voci JBoss-u, ty programujes v Java EE a to je vsetko co ta musi trapit, od toho sa to vola referencna implementacia, ze mozes vymenit aplikacny server a musi to fungovat. Inak by to nebola referencna implementacia. Ked oba servery implementuju nieco podla standardu, ako by bolo potom mozne, ze ked spustis dva projekty na kazdom z nich, tak na jednom nepojde a na druhom ano? Potom asi jeden z nich neimplementuje podla referencie ...
Hej, to som predpokladal. Ale zivot a test reporty ma naucili brat kompatibilitu SW trochu skepticky. Ako presne je to vo svete Java EE a aplikacnych serverov?
a) Neexistuje, ze by ti to neslo, taky problem som nikdy nevidel (takto tvoja odpoved posobi).
b) Vacsinou s tym nie je problem, zriedka narazim na nejaku drobnost.
c) Spustit aplikaciu pod inym servrom je vstup na zaminovane pole a nekonecny zdroj skrytych chyb.
-
Hej, to som predpokladal. Ale zivot a test reporty ma naucili brat kompatibilitu SW trochu skepticky. Ako presne je to vo svete Java EE a aplikacnych serverov?
a) Neexistuje, ze by ti to neslo, taky problem som nikdy nevidel (takto tvoja odpoved posobi).
b) Vacsinou s tym nie je problem, zriedka narazim na nejaku drobnost.
c) Spustit aplikaciu pod inym servrom je vstup na zaminovane pole a nekonecny zdroj skrytych chyb.
Schvalne neodpoviem, pockam si na nazor druhych, som zvedavy ako sa na to pozeraju oni :)
-
http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html
nemozem povedat nabeton ale urcite nieco medzi a) a b) (v kontexte tvojej otazky)
-
NIe malo ale musi, ty neprogramujes voci nejakeku GlassFishu alebo potom voci JBoss-u, ty programujes v Java EE a to je vsetko co ta musi trapit, od toho sa to vola referencna implementacia, ze mozes vymenit aplikacny server a musi to fungovat. Inak by to nebola referencna implementacia. Ked oba servery implementuju nieco podla standardu, ako by bolo potom mozne, ze ked spustis dva projekty na kazdom z nich, tak na jednom nepojde a na druhom ano? Potom asi jeden z nich neimplementuje podla referencie ...
Hehehe, teoreticky ;) (realne zkusenosti s JBoss, WAS, ...)
Minimalne budes muset delat custom deployment descriptory a podobne. Pokud ale budes delat nejakou velkou app, tak zjistis, ze se lisi. Samozrejme jednoduche app pujdou prenaset, ale u tech slozitejsi stejne budes muset testovat i nad ostatnima AS (kazdy AS ma nejake bugy (features, tj implementator si dane JSR vylozil mirne jinak). Proto mam radeji Spring, kde resis jen 1 implementaci (oproti nekolika implementacim u aplikacu) a testujes jen jak moc kompatibilni je implementace servlet kontejneru.
-
NIe malo ale musi, ty neprogramujes voci nejakeku GlassFishu alebo potom voci JBoss-u, ty programujes v Java EE a to je vsetko co ta musi trapit, od toho sa to vola referencna implementacia, ze mozes vymenit aplikacny server a musi to fungovat. Inak by to nebola referencna implementacia. Ked oba servery implementuju nieco podla standardu, ako by bolo potom mozne, ze ked spustis dva projekty na kazdom z nich, tak na jednom nepojde a na druhom ano? Potom asi jeden z nich neimplementuje podla referencie ...
Hehehe, teoreticky ;) (realne zkusenosti s JBoss, WAS, ...)
Minimalne budes muset delat custom deployment descriptory a podobne. Pokud ale budes delat nejakou velkou app, tak zjistis, ze se lisi. Samozrejme jednoduche app pujdou prenaset, ale u tech slozitejsi stejne budes muset testovat i nad ostatnima AS (kazdy AS ma nejake bugy (features, tj implementator si dane JSR vylozil mirne jinak). Proto mam radeji Spring, kde resis jen 1 implementaci (oproti nekolika implementacim u aplikacu) a testujes jen jak moc kompatibilni je implementace servlet kontejneru.
Přesně tak, v reálném světě Java EE aplikace rozhodně nejsou nezávislé na aplikáči. To co tvrdí nn, že to prostě musí fungovat, je jen nezkušenost :) A nejsou to jen jiné implementace standardů, ale i opravdové bugy. Snad nejste tak naivní, abyste věřili že existuje nějaký AS bez bugů ;)