Proč je JavaEE nepopulární?

[Radek Miček]

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

[Reklama]

[minimir]

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

[student]

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

[minimir]

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

[Radek Miček]

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.

[Reklama]

[minimir]

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

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

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

[Radek Miček]

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.

[Radek Miček]

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

[Natix]

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

[Radek Miček]

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.

[neruda]

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

[Biely plemenny had]

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?

[Mirek_]

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.

[Biely plemenny had]

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