Ebben a post-ban szeretném felsorolni azon Java library-ket, keretrendszereket, melyeket legszívesebben használok különböző webes alkalmazások fejlesztése közben. Ezekkel rengeteg tapasztalat gyűlt fel, és mindenkinek bátran ajánlhatom őket. Érdekes lesz visszanézni egy-két év múlva, hogy hol tartanak. Remélem ti is merítetek belőle hasznos ötleteket, és a véleményeteket is várom, hogy milyen eszközöket használtok, az általam használt stack mely elemeit lenne érdemes kicserélni Az eszközöket tetszési sorrendben írom, a kedvenceim elől, azok, melyekkel kényelmes fejleszteni, amelyekben keveset csalódtam.
Spring: Kvázi szabvány keretrendszer dependency injection-nel, inversion of control-lal. A J2EE kiváltására találták ki, annak bonyolultságának mellőzésével. Annak szolgáltatásait nagyrészt biztosítja (talán néha a lokális transzparencia hiányzik egyedül). Ugyan a Java EE 5 már sokkal egyszerűbb, a Spring-ből rengeteg elemet át is emelt, mégis a lassú szabványosítási folyamat miatt a Spring már elhaladt mellette. Legnagyobb előnye, hogy apró lépésekben is bevezethető (pl. több éves projektben pár nap alatt vezettük be a perzisztencia rétegbe), és nem igényel alkalmazásszervert, melyekkel rengeteg rossz tapasztalatom volt. Számomra az egyik legfontosabb szempont fejlesztés közben a nagyon rövid fejlesztési ciklus, azaz hogy egy módosítás max. 30 másodpercen belül kipróbálható legyen. JDBC esetén nagyon hasznos a JDBC abstraction layer, JPA estén inkább a standart JPA API-t használjuk.
Spring MVC: Webes keretrendszer, mely elég magas szintű, értelmes default konfigurációkkal rendelkező, annotációkkal konfigurálható a gyors haladás érdekében, de elég alacsony szintű is, ha kell, pl. a request, session, stb. objektumok is könnyen elérhetőek. Összevetve a JSF és Wicket keretrendszerekkel talán kevésbé objektumorientált, kevésbé komponens alapú, de sajnos olyan tapasztalataink voltak az eddigi megrendelőkkel, hogy képesek a keretrendszerek határait feszegetni. A Spring MVC-vel mindent egyszerűen meg lehet csinálni, amire az amúgy silány HTTP protokoll és HTML formátum, és társai lehetőséget biztosítanak. E mellett a Struts-ot is szeretem, de ez jobban illeszkedik a Spring-hez. Ami külön tetszik, hogy sokszor voltam úgy, hogy dokumentáció nélkül elgondoltam, hogy így kéne működnie, kipróbáltam, és tényleg.
Apache Log4J: Apró és megbízható segítség a naplózáshoz. Ugyan jönnek a trónkövetelők, mint a Logback, SLF4J, azonban nem tudok elképzelni olyan funkciót, amiért váltanék, és még nem is annyira elterjedtek. Erről cikket is írtam.
Apache Velocity: Sablonozásra használjuk. Régebben ez volt a view réteg, de most inkább a JSP, mely jobban megköti az ember kezét. Nem csak alkalmazásokban használjuk, hanem pl. ügyfél számára interfész prototípus, sőt dokumentáció generálására is. Okosabb a FreeMarker, de nem volt még szükség a funkcióira. Erről szóló cikk.
Apache Lucene: Most már mindegyik webes alkalmazásban szükség van a tartalom hatékony keresésére, erre tökéletes. Erről cikket is írtam.
Spring Security: Autorizációra és autentikációra kizárólagosan ezt használjuk. Erről nemrég írtam a Spring Security post-omban.
JSP, JSTL: Szabványos view réteg, aminek ugyan vannak hiányosságai, de rákényszerít a helyes MVC használatra, és az IDE-k is ezt támogatják a legjobban.
Display tag library: JSP tag library táblázatok megjelenítésére. Ami kellett, azt még mind tudta. Akár AJAX bővítménye is van. Van régebbi post erről is.
JUnit: Unit test-ek fejlesztésére, az elterjedtsége miatt. A TestNG is rendkívül szimpatikus, de egyelőre nincs olyan funkció, melyért váltanék, kockáztatva a támogatottságot.
Direct Web Remoting: Kellően alacsony szintű bridge a Java és a JavaScript világ között, AJAX-os funkciók megvalósítására.
jQuery: Bár alapjában véve gyűlölöm a JavaScript-et, ez a library nagyon hasznos segítségnek bizonyult. A Prototype annyira nem hatott meg.
JasperReports és iReport: Riport generálásra használatos library és NetBeans alapú riport tervező eszköz. No ez már jó pár napom megkeserítette, de még mindig ez a legszimpatikusabb. Az XSL-FO általában ágyúval verébre, és iszonyatosan lassú és erőforrás igényes. A másik versenyző a BIRT, amivel nem sok tapasztalatom van, és amúgy is az Eclipse ökoszisztéma tagja.
Hibernate: Az egyik legelterjedtebb ORM megvalósítás. Történelmi okok miatt nem váltottunk az EclipseLink-re, de nem vagyok elkötelezett híve, mert sok nehéz pillanatot szerzett. Kizárólag JPA provider-ként használom.
A listából is látható, hogy olyan eszközöket igyekszem választani, melyek vagy szabványosak, vagy kvázi szabványosak. Egy konkrét problémát célozzanak meg, és elég egyszerűek ahhoz, hogy probléma esetén akár a forrását tanulmányozva, vagy debug-olva előrébb lehessen jutni (az nyílt forráskódú szoftverek legnagyobb előnye, ha már a dokumentációjuk hagy némi kívánnivalót maga után). Jelentős forrásanyag (tutorial, projekt reports, dokumentáció, példakódok, cikkek, könyvek), felhasználótábor (hírek, fórum, levelezési lista, issue tracker) legyen körülötte. Külön fontos, hogy nagyon egyszerűen, lépésekben bevezethető, könnyen tanulható legyen, hogy hamar sikerélményt biztosítson. És szép legyen a weboldala.
A következő post-ban az általam leggyakrabban használt Java-s tool-okat, eszközöket fogom bemutatni.
Ti milyen library-ket, keretrendszereket javasoltok? Főleg olyanok érdekelnek, melyeket éles projektben használtatok, beváltak, újabb projektekben is bevetnétek, és több hónap után is szívesen nyúltok hozzá vissza.

Apache Digester nagyon kellemes meglepetést okozott olyan esetben amikor a DOM túl erőforrásigényesnek, a SAX pedig macerásnak bizonyult.
VálaszTörlésaz én bevált musthave listám az elhangzottakon kívül: wicket, mockito, aspectj (és maven2 és mercurial, de java libeket kérdeztél).
VálaszTörlésMiért idegenkedsz az Eclipse cuccoktól? BIRT-tel pont nincs tapasztalatom, de alapvetően nagyon jók szerintem.
A JQuery-vel szemezgetek én is. Emellett még az extjs és a YUI van versenyben.
VálaszTörlésAz extjs-t a licenszelés miatt érzem problémásnak. (Ha nem open source projektet akarok csinálni akkor borsos az ára.) A YUI ígéretes, a JQuery-ben viszont nem látok egy homogén GUI komponens könyvtárat, ami miatt az egész kellene nekem. Bár lehet hogy csak rossz helyen keresgélek. Mindenki által írt külső plugineket találok, node ezekben mennyire lehet megbízni? Ezeknek is összevissza van a licenszelése gondolom.
Egyéb java könyvtárak amiket megelédeséssel használok: mindenféle Apache cuccok (jetty, poi, commons, beanutils, stb.)
A YUI-t nehogy használd!!! jQery-hez van a jquery-ui, nézzd meg azt.
VálaszTörlésEz egy nagyon jó összefoglaló, köszönöm szépen. Én most egy szervert csinálok, amiben hibernate-et használok. Akérdésem az, hogy érdemes-e ezt spring-el és jdbc-vel csinálni? A szervernek semmilyen felhasználói felülete nincsen. (illetve van, csak az php-ban van megvalósítva.)
VálaszTörlés@Névtelen: Én ilyen esetekben a standard JAXB-t vagy ahol fontos a sebesség, a StAX-ot, régebben a JDOM és dom4j is szerepelt a palettán.
VálaszTörlés@Kristóf: Wicket és Mockito már régóta a queue-ban van, mindenképp ki fogom őket próbálni. Az Eclipse cuccok nekem mindig kicsit pilótavizsgások voltak, de amúgy nem zárkózom el előlük. Úgy éreztem, hogy nehezebb velük elindulni, de aztán többet lehet kihozni belőlük. Ha a JasperReports-szal valamit nem tudok majd megoldani, tuti a BIRT lesz a következő versenyző.
@pcjuzer: Mi igyekszünk a standard HTML felhasználói felületnél maradni, amíg lehet, így a csilli-villi komponensekkel nem nagy tapasztalatom van. Eddig a jQuery UI tab-ját használtam, valamint a jsTree fa komponenst, azokkal nem volt baj.
@sajt: a Spring szerintem mindenképp jó választás, hogy az alatt JDBC-t vagy JPA-t, esetleg Hibernate-et használsz, az már az alkalmazástól függ. Az első kettő közül javaslom, hogy válassz. Ha az alkalmazás már sok meglévő táblát használ, ahol a séma nem egészen 3. NF-ban van, és nagy adattömeggel dolgoznak, esetleg ki akarod használni az adatbáziskezelő tulajdonságait (pl. erősebben támaszkodsz tárolt eljárásokra), akkor JDBC. Ha te tervezheted meg az adatbázist, főleg entitásaid vannak, egyszerűbb táblákkal, kapcsolatokkal, kisebb adatmennyiséggel, és az üzleti logika a Java oldalon van, akkor JPA. Sőt a kettőt keverni is lehet, pl. JPA lehet az üzleti entitásai kezelésére, de JDBC a riportok kezelésére, vagy nagy választási listák kezelésére. Ha jól emlékszem, ez utóbbi a Value List Handler tervezési minta.
EHCache, WhirlyCache - cacheléshez
VálaszTörlésiText - Pdf készítéshez
apache commons-* - Sokmindenhez
Az SLF4J-ben nagyon kellemes a {}-es behelyettesítés.
VálaszTörlés