Proč je JavaEE nepopulární?

[Franta <xkucf03/>]

…

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.

[Reklama]

[eMko]

…

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).

[Radek Miček]

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).

[podlesh]

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é.

[Franta <xkucf03/>]

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.

[Reklama]

[Štěpán]

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í.

[Franta <xkucf03/>]

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.

[Radek Miček]

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ý.

[eMko]

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".

[minimir]

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

[kvr kvr]

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ší...

[neruda]

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.

[eMko]

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ý).

[eMko]

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.

[eMko]

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.