Érdekelne a véleményetek, hogy ki mit preferál. Szeretem mindkettőt és a JEE6-al sok jó dolog megjelent, de amit problémásnak érzek az még mindig a tesztelhetőség... A fejlesztés gyors és a CDI jó dolgokat hozott, de hogy a teszteléssel többet szívjon az ember, mint a fejlesztéssel, ez valahogy nem tetszik. JUnit-os tesztek készítésére ott az embedded-glassfish vagy az arquilian. Mind a kettőnek szerintem egsz sok nyűgje van és én mást nem is ismerek amivel a konténer menedzselt serviceket tesztelni lehetne. Ebben a tekintetben szerintem még mindig jobb a Spring, persze ott nincs konténer, ezért is egyszerűbb a tesztelése. Igaz a fejlesztés több kódot igényel, viszont valahogy közelebb érzem magamhoz, jobban látom, hogy melyik bean mikor jön létre és itt még függőségi sorrendet is meg tudok adni, míg CDI-nál van a sepc, és majd valahogy létrejön. Ráadásul a JBoss-t elég bugosnak tartom és Glassfish-nél is találkoztam bugokkal, amit érzésem szerint Springben egyszerűbben tudok javítani, jobban belenyúlhatok. Pl. alkalmazás szerver szinten még a JPA provider kicserélése is problémát jelenthet, ha pl. valami újabbat szeretnék használni, mint amivel az alkalmazásszerver jött. Persze, a JEE nagy előnye a SessionBean, mivel akár admin felületről is dobhatok a performancián a pool méretezéssel, bár business object poolozásra Springben is van lehetőség... Ti mit gondoltok?
19 Comments
Auth Gábor
Ebből flame lesz... ezért inkább alszom rá egyet...
Simon László
Egyáltalán nem a flame kedvéért nyitottam, csak kiváncsi vagyok mások tapasztalataira. Szerintem a JEE6 fejlesztésre tényleg nagyon jó, pár apróságtól eltekintve, de ha tesztelni is kell, akkor már érzésem szerint jönnek a problémák, ez könnyebb Springnél. De az is lehet, hogy nem tudok valamit amit más igen és ő elmagyarázhatná, hogy ezért meg azért gondolom ezt rosszul.
Megpróbálom összeszedni, ahogy én látom:
JEE6 előnyei:
hátrányai:
Spring előnyei:
hátrányai:
Papp Gergely
Csatlakozom az előttem alvóhoz.
Simon László
Még annyi, hogy Springnél találtam bejegyzést támadhatóságról, gyakorlatilag idegen jar-t/támadó kódot fel tudtak játszani egyszerűen a szerverre a Spring valamilyen hibája miatt. Ilyesmit eddig még JEE szerverről nem találtam, így talán biztonságosabbnak is mondható a JEE.
Czimmermann Gábor
Szerintem felesleges flame-et indítani. Ez kb. olyan, mintha a Trabantot hasonlítanánk az IFA-hoz.
Simon László
Mint irtam, nem flame-t szandekoztam inditani, hanem erdekelne mas hogyan latja ezen dolgokat. Ha elolvastad amit irtam, akkor lathatod, hogy megprobaltam osszeszedni az elonyoket es hatranyokat es talan egyiket sem tuntettem fel negativ szinben, probaltam targyilagos maradni. Szoval nem ertem a problemaitokat... De OK, tudomasul vettem.
Auth Gábor
A szándék nem okoz flame-t, csak a téma...
A Spring remek eszköz volt a JavaEE 1.3 és 1.4 környékén, amikor az EJB2.x volt az alternatív megoldás, kitöltötte azt a piaci rést, amely a Java Serlvet/JSP és a JavaEE között volt. Tudni kell, hogy az EJB2.x nem egy egyszerű dolog volt, igencsak nehéz volt alkalmazásokat építeni, de a legfőbb probléma egyszerűen az ingyenesen elérhető alkalmazás szerverek hiánya volt: a JBoss 3.x és 4.0.x nem volt a helyzet magaslatán, a többi alkalmazás szerver pedig igen drágán volt csak elérhető, így a kisebb cégek nem tudtak JavaEE technológiákra építeni, nem volt más alternatíva, mint a Spring.
A JavaEE 5 hozta a fordulópontot, mivel megjelentek a open source JavaEE konténerek, illetve az EJB3.0 hihetetlen mértékben egyszerűsítette a fejlesztést, a JavaEE annyira egyszerű lett, mint a Spring volt... mostanság a JavaEE annyira elterjedt, hogy már erősen keresni kell olyan konténert, amely nem tudja a JavaEE5-öt... és persze ott a kényelem: egy JBoss 7.1 kevesebb erőforrást eszik full profile indítva, mint egy Tomcat, miközben sokkal könnyebb konfigurálni, menedzselni és ott a teljes JavaEE6 tudás...
Meglátásom szerint a Spring esetén még mindig alacsonyabb a küszöb, könnyebb működő alkalmazást összeállítani, mint JavaEE6 használatával, az általad leírt előnyök és hátrányok nagyjából stimmelnek. De az alacsonyabb küszöb mellé azonban Spring esetén van egy alacsonyabb plafon is: amikor cluster-safe alkalmazásokat kellene írni, illetve tranzaktált terhelést elosztani vertikálisan és horizontálisan. Ez JavaEE esetén out-of-the-box működik, Spring esetén már maga a cluster is sokszor kihívás, több rétegű alkalmazás esetén a tranzaktált load-balancing meg már sci-fi.
Amikor az ember keretrendszer választ, akkor érdemes megnézni a küszöböt és a plafont, mert hiába könnyű belépni, ha pár lépés után a fejünk a plafont súrolja...
Simon László
Köszi, hogy megtörted a csendet...
Amit leírtál, annak többségével egyet értek. Amiben nem, azon dolgok egy része szubjektív, mert én Veled ellentétben úgy gondolom, hogy JEE5 vagy 6-al is gyorsabb a fejlesztés, mint Springgel. Viszont a tesztelés szerintem határozottan egyszerűbb Springgel. Ez valahogy nekem hiányzik JEE-ből...
Az alkalmazás szerverek tekintetében igazad van, bár a JBoss azért elég bugos volt, de ez az utolsó 7.1, már egész tűrhető még sebességben is. Esetleg annyit meg lehet jegyezni, hogy a Springnek sem kell feltétlen Tomcaten futni, futhat az is Jboss-on, ha kell. Legutóbbi projektemben az összeállításkor próbálgattam dolgokat és azért 7.1-nél tapasztaltam olyan dolgot, amik Glassfish 3.1.2 alatt simán futottak, JBoss7.1 meg kiabált..., sőt ugyanaz még 6.1.0-nál is működött. (Service injektálás ear lib alatti utility-be)
A skálázhatóság teljesen egyértelműen a JEE felé húz. Tudsz esetleg projekt bonyolultságot(konkurens userszám) mondani, ami felett nem érdemes Springet használni?
Auth Gábor
Ööö... izé... a tesztelés nem része a fejlesztésnek?
Nyilván futhat WebSphere-n is, láttam már erre példát... de ettől még elég egy Servlet/JSP konténer a futásához...
Ennek az az oka, hogy az alkalmazás szerverek fejlesztőinek más-más a fontos, a szabványt mindegyik megvalósítja, aztán más-más területen terjesztik ki azt. Ha a projekted a JavaEE határain belül marad, akkor futni fog mindegyik alkalmazás szerveren, ha pedig túlmész néha a határon, akkor igazítani kell az alkalmazáson.
Erre nincs számszerű válasz, feladattól és architektúrától függ. A Spring-es projektek egyik problémája, amikor kicsiből nagyobb lesz terhelés és nincs hova lépni, mert egy gépen szépen dolgozott, de kettő gépen kiderül, hogy milyen adatok nem replikálódnak (tipikusan sticky session pattern), aztán amikor több tucat gép kell, akkor kiderül, hogy a replikáció se hatékony megoldás, ésatöbbi. Ha tudod, hogy nem lesz nagy tranzaktált igénybevétel, akkor teljesen jó a Spring, ha viszont várható, hogy vertikálisan és/vagy horizontálisan kell a terhelést elosztani, akkor azzal problémák lesznek.
Az is igaz, hogy jó Spring-es embert könnyebb szerezni, mint jó JavaEE-s embert... mert attól, hogy a platform remekül képes skálázódni, attól még képesek a fejlesztők ezt remekül eltoszni...
Czimmermann Gábor
Sajnos az, hogy Spring, vagy JEE nem csak a terheléstől függ, hanem főként a feladattól. Például egy elosztott (cluster) rendszer esetén a JEE szolgáltatásokat sokkal könnyebb rábízni a konténerre, mint mindenféle pluginekkel játszani.
Én azt gondolom, hogy akkor tudsz igazán dönteni, ha pontosan tudod mit akarsz csinálni és mindkét eszközt (szabványt, framework-öt, stb.) alaposan megismered.
Szerencsére a neten elég sok jó doksi található erről. Az a fontos, hogy egyik oldal híveire se hallgass, ha nem tudnak megfelelő megoldást mondani a problémára.
Mint ahogy Gábor lejjebb írja, nagyon sok a tapasztalatlan fejlesztő mindkét oldalon.
A lényeg: 80% tervezés 20% kódolás!
Czimmermann Gábor
Gábor, sajnos le kell, hogy törjem a JBoss iránti lelkesedésed. Mondhatni a 7.1.1 egy rakás szar.
Fejlesztek, tesztelek egy 12 gépből álló clusteren futó alkalmazást , ami a JBoss 7.1.0-n tökéletesen fut (kivéve, hogy a relay a DC-k között ott sem megy), azonban a 7.1.1-nél olyan értelmetlen hibaüzenetek jelennek meg, hogy semmi utalás sincs a hiba valódi okára.
A másik, ami a JBoss-ban hihetetlenül jó, hogy néhány alap JEE szabványt is másként értelmez és a dokumentációja jóindulattal is jegyzetnek nevezhető.
Én azt mondom, ha csak web alkalmazás, akkor Spring, ha elosztott szolgáltatás, akkor JEE.
Az, hogy jó valaki vagy sem, az nem attól függ, hogy Spring, vagy JEE.
Auth Gábor
Ööö... én nem lelkes vagyok, hanem realista...
Valószínűleg kiléptél a JavaEE6 határán, amelyet a 7.1.0 még tolerált, a 7.1.1 pedig már nem... egyébként érdemes TRACE szintre tenni a logolást, meglepően sok információt közöl a JBoss a működéséről és a hibákról.
Ezt értem, de tipikusan nem "web alkalmazás" használati eseteként került szóba a Spring.
Én csak annyit írtam, hogy minden technológiának és keretrendszernek van egy küszöbe és egy plafonja. A küszöb akkor fájdalmas, ha nem tudja átlépni az ember, a plafon pedig akkor fájdalmas, ha eléri.
Czimmermann Gábor
Tényleg nem akarok flame-et!
>Valószínűleg kiléptél a JavaEE6 határán, amelyet a 7.1.0 még tolerált, a 7.1.1 pedig már nem... egyébként érdemes TRACE szintre tenni a logolást, meglepően sok információt közöl a JBoss a működéséről és a >hibákról.
Sajnos nem én léptem ki, hanem a JBoss, ami azért fura, mert a 7.1.0-ban és a 7.1.1-ben nem ugyanaz az eltérés a szabványtól. (pl. névterek, erőforráskezelés, stb.)
Ha gondolod írok egy cikket a tapasztalataimról. A 6, 7.0, 7.1.0 és 7.1.1 szerverek teljesen másként konfigurálódnak és másképp is működnek.
A Spring esetén az "elosztott" szolgáltatást hiányolom, azaz a szolgáltatás a web-tier része és nem az enterprise szervíz konténer menedzseli. Azaz a Spring határozza meg az erőviszonyokat és nem a konténer.
Így értettem.
A többivel egyetértek.
Simon László
Igen, en is azt erzem, hogy a JBoss egyzser igy, masszor amugy mukodik egy verziovaltast kovetoen... Ezert dontottem inkabb ugy, hogy fejlesztes alatt Glassfish, aztan az eles kornyezetben majd meglatjuk mi lesz. De igy legalabb megfelelek a ref implementacionak... Pl. a 6.1 szerintem meg talan most sem felel meg a JEE5 specnek (persze mar meg sem fog). Jol emlekszem a @Singletone-t tuti nem ismerte. Az ok, hogy a 7.1 igen, de hat azert az nem regen jott ki.
A Spring-el kapcsolatban amit irsz, egyetertek. De neha pont ezert "csabulok" el, mert par dolgot szerintem pont azert lehet esszerubben elkesziteni, mert ott ugy alakitom a mukodest, ahogy nekem tetszik, mig a kontener eseteben megbziom abban, hogy spec szerint csak jol mukodik. Egyebkent tobbnyire igen, nincs olyan nagy baj vele. De pl. a szalkezelest kicsit hianyolom belole, persze ez galibakat is okozhat, ertheto, hogy miert nem eroltettek.
Papp Gergely
A JBoss 6.1 a JEE5 specifikáció keretein belül azért nem támogatta a @Singleton-t mert az JEE6 spec.
A többiben Gáborokkal nagyrészt egyetértünk.
A szálkezeléssel pls. ne komolytalankodjunk. A JEE alapú megközelítések az erőforrások direkt kezelését, így a szálkezelést is a container-re bízzák, részint, hogy azok felhasználása kontrolláltan történjen, részint, hogy a fejlesztőnek ne kelljen ezzel foglalkozni. Ha JEE-ben a szálak kezelése olyan, mint a JSE-ben a memóriakezelés. Ha szükséged van rá, akkor valamit nagyon benéztél!
A "flexibilis" megoldások és a keretrendszerből kinyúlások nagyon rövid távon karbantarthatatlan és továbbfejleszthetetlen kódkupacokat eredményeznek. Ezzel pályám során rengeteg alkalmam volt találkozni. Sokan nem tudják belátni, hogy nem okosabbak azoknál a keretrendszerek és szabványok kidolgozását végző profiknál és megpróbálják azokat megkerülve "hatékonyabb" és "egyszerűbb" megoldásaikkal behálózni a kódot. Gyakran kerülök olyan helyzetbe, amikor régi kódok elemzésénél felmerül a kérdés, hogy "Mire is gondolt a költő?". Egyik "kedvenc" ilyen megoldás az Exception-ök manuális dobálásával, azok több ősosztállyal feljebb elkapásával az üzleti logika lefutásának irányítása. Itt már azonban gyanús, hogy a költő igazán vonzódott a különböző zőldfűszerekkel megszórt gombafélék LSD-be mártott kokalevélbe csavarásához, majd elszívásához, gondolkodni pedig már nem szokott.
Amúgy meg a Confluence is Springben készül, tehát ez a beszélgetés sem jöhetne nélküle létre. (Hozzáteszem a nagy okosságokat Auth kolléga már leírta előttem, mert Android browserből még nem használható a felület)
Auth Gábor
Android support vagy lesz vagy nem lesz: https://jira.atlassian.com/browse/CONF-25529
Simon László
Igaz, JEE6 spec, de mar a JBoss 6.1-et JEE6 kompatibiliskent fejlesztettek, ami nem jott ossze, csak a 7-ben.
Nem neztem be semmit es hidd el tisztaban vagyok vele, hogy mi a koncepcio. Tobbsegeben nem kell, de van ugy, hogy egy hosszabb projektnel olyan dolog jon elo, amire kezdetekkor nem keszulhettel es volt olyan eset, amikor nekem jol jott volna. Egyebkent feltetelezem, pont ezen igenyek miatt vezettek be az @Asynchronous-t JEE6-ban.
Auth Gábor
Technology preview volt.
Tiszta sor, sok minden jól jönne, amikor egy hosszabb projektnél kiderül, hogy baj van az alapokkal... csak amikor az élesbe állítás után üzemeltetés közben a pillanatnyi igények kibillentik a szervert a komfortzónájából, akkor nem mindegy, hogy az üzemeltetés képes beavatkozni és a thread pool méretét EJB szinten módosítani, hogy a fontos funkciók továbbra is működjenek és a kevésbé fontos funkciók lassuljanak be vagy dobjanak timeout-ot, vagy sem.
A szálak szabad indítása azért tiltott dolog, mert a konténer dolga a Quality of Service biztosítása, és bizonyos alkalmazás szerverek meg is próbálják az előírt SLA-t betartani az erőforrások elosztásával, azt pedig csak úgy lehet, ha a futó programok nem maguk kezelik az erőforrásokat, hanem a konténer biztosítja azokat. Spring esetén ez a koncepció hiányzik, olyan, mint annó a DOS volt egy Unix rendszerhez képest: sokkal szabadabb, sokkal gyorsabb, sokkal rugalmasabb, ugyanakkor sokkal sérülékenyebb és jóval kevéssé felügyelhetőbb.
Simon László
Szerintem Technology preview lett... ha rossz indulatu akarok lenni
Nem az alapokkal volt baj, hanem az igenyek valtozasaval. Eleve az ember elore gondolkozik amennyire lehet, hogy rugalmas legyen a projekt, de minden eshetosegre nem lehet szamitani. Az ugyfel meg sajnos azt hiszi, hogy hat meg "ezt a kis aprosagot kerem", csak az nem aprosag valojaban.
A tobbivel egyetertek, amikor nyitottam a temat es a JEE elonyeit soroltam, pont ezt irtam, hogy a service reteg es annak teljesitmenyre hangolasa nagyon kellemes dolog. Viszont az, hogy a szalkezeles valos problema volt onnan is latszik, hogy a JBoss is probalt az alkalmazasszerverbe beepiteni ilyen funkciot(mar nem emlekszem milyen class-kon keresztul) korabban, amivel ez megvalosithato. Egyebkent, osszesen csak egyszer lett volna ra szuksegem, de hat kerulo megoldassal is sikerult elernem amit szerettem volna, ez csak egy alternativ lehetosegkent merult fel.