"Az Eclipse Foundationnek adja át a Java EE-t az Oracle"

Java

"A kiszemelt Eclipse Foundation nonprofit szervezetet 2004-ben alapították, eredetileg a nyílt forrású Eclipse projektek irányítására, illetve fejlesztésére. Az alapítvány stratégiai partnerei között ott van az IBM, a Red Hat, az Ericsson, az SAP és persze az Oracle is, összesen pedig nagyjából 250 tagot számlál, több technológiai szegmensből. Az Eclipse IDE fejlesztését célzó projekt mellett a cég nevéhez fűződik egyebek mellett a SOA Platform Project, iletve a WTP Project is. Az Oracle-nek azért esett a választása az alapítványra,mert annak kiterjedt tapasztalata van a Java EE és a hozzá kapcsolódó technológiák terén, ami a platform átállását is megkönnyíti és gyorsítja majd az új vezetés alá."

További részletek itt.

( profeta | 2017. 09. 14., cs – 12:17 )

Teljesen mindegy mi történik ezzel a versenyképtelen óriási szarrakással, aminek a "fejlesztése" kimerült más rendszerekben bevált megoldások több év késéssel történő átvételében.
Nem kis mértékben okozta a Java rossz hírét.
Persze a tehetetlenség viszi majd még legalább tíz évig, sajnos rengeteg rendszer ebben készült. De aztán majd oda kerül, ahová való: a szemétdombra.
A Spring pedig ezerrel nyomul befelé a piaci résbe (Az hogy ez most jó vagy nem, az más kérdés. A konkurencia hiánya sosem jó.)

én 3.x-szel dolgoztam utoljára, meg egy picit 2.1-gyel.

az életciklus elképzelése egy komplett marhaság volt, így egybe, az egész.

elosztott tranzakciókezelés lehetséges volt benne, csak hatalmas szívás.

a perzisztenciakezelésének voltak gyereknyűgjei, ami miatt ha már volt egy meglévő adatbázisod, akkor ahhoz kb. lehetetlen volt a beépített mappinget alkalmazni.

a webservice-ek, amiket kiexportált magából, azok is olyanok voltak, hogy volt egy elképzelése a világról, ami nem feltétlenül felelt meg annak amit te tényleg akartál. Na nem mintha a JSON nem dózerolta volna a földbe az összes SOAP alapú cuccot, ahhoz meg hogy custom építgess JSON-alapú dolgokat iszonyat drága volt teljesítményben.

és hát a legvége az, hogy az egész nagy, nehézkes és lassú volt. Ha tudtad, mit akarsz, akkor a PHP pozitív mintáit alapul véve (a service-nek nincs saját perzisztenciája, azokat különböző szintű és típusú perzisztenciaszolgáltatók adják, JSON-ban gondolkozunk, stb), Spring vagy Play alapon lightweight röhögve megépítettél bármit amire a Java EE képes akart lenni. A gyakorlatban mindig az volt hogy hát ez egy szép elmélet.

Nem feltétlenül a futtatás a lassú. Bár ha valaki nem ért hozzá, az is megoldható.
A fejlesztés/fordítás/deploy ciklus sebessége ami tragikus. Persze erre is van megoldás, főleg pénzért, illetve mostanra egyszerűsítettek rajta valamit, de a régi jó enterprise alkalmazásoknál simán volt 10 perc fordítás, 2-3 perc deploy.

De a világon nem volt akkora galamb amihez ez megfelelő méretű ágyú lett volna.

Kis rendszerekhez nem volt jó, mert sokkal gyorsabban lehetett Springgel eredményt elérni.

Nagy rendszerekhez nem volt jó, mert a Spring könnyűsége miatt sokkal jobban skálázódott (akár pl. deployban, vagy abban hogy az alacsonyabb IQ-jú kollégák felfogják a működését)

Közepes rendszerekhez nem volt jó, mert nem nyújtott sokkal többet a lightweight rendszerekhez képest.

( csababoro | 2017. 09. 15., p – 20:06 )

A Java EE 5 előtt elég nehézkes volt benne fejleszteni. Szerintem a Java EE 8 alatt már nagyon könnyű a fejlesztés. Szerintem a python, ruby php segítségével sokkal nehezebb komplex megoldásokat készíteni. Fikázás helyett érdemesebb elolvasni a Java EE dokumentációt....