- A hozzászóláshoz be kell jelentkezni
- 3344 megtekintés
Hozzászólások
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ó.)
- A hozzászóláshoz be kell jelentkezni
Konkrétan mi a bajod a JAVA EE-vel?
- A hozzászóláshoz be kell jelentkezni
Ha nem ismered, nem innen fogod megtudni, könyvet lehetne írni róla.
Ha ismered akkor érezhetted a saját bőrödön.
Ha ismered és szereted... Hát... Végül is nem vagyunk egyformák, szerencsére.
- A hozzászóláshoz be kell jelentkezni
é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.
- A hozzászóláshoz be kell jelentkezni
A lassú kérdéshez persicsb csinált egy tesztet:
https://hup.hu/node/154960?comments_per_page=9999#comment-2134484
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
A tesztet nem én csináltam, hanem _Franko_
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
nem ért hozzá, azért fikázza
- A hozzászóláshoz be kell jelentkezni
Szerintem abba a komponensmodellbe hinni kell, nem érteni hozzá (amúgy van belőle valami certificate-em, de 2008-ból)
- A hozzászóláshoz be kell jelentkezni
Jó hát végülis religion bizonyos szinten :)
- A hozzászóláshoz be kell jelentkezni
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....
- A hozzászóláshoz be kell jelentkezni