A Java programozási nyelv nem régiben ünnepelte 25. születésnapját, ennek ellenére – vagy pont emiatt – népszerűsége még mindig töretlen. A Java fejlesztése az utóbbi időszakban felgyorsult, viszont az ipar nagy része még nem idomult a gyors váltásokhoz. Ez hosszútávon azt okozhatja, hogy a technológiai szakadék egyre nagyobb lesz a „lemaradó” cégeknél, és a váltás már egyre nehezebb és költségesebb feladattá válik az idő haladtával.
Cikkemben ezért körbejárom a Java verzióváltás témakörét és sorra veszem, milyen előnyökkel és hátrányokkal járhat. Tarts velem!
A Java verziók tengerében
A Java programozási nyelvet 1990-ben a Sun Microsystems fejlesztette ki és fejlesztette egészen 2009-ig, amikor is az Oracle felvásárolta a céget.
Az Oracle a Java SE 8-as verzióig csak néhány évente adott ki új verziót (A Java SE 6 és Java SE 7 között majdnem 7 év telt el). Ez a rendszer kezdett lassúnak bizonyulni a többi programozási nyelv dinamikus fejlődéséhez képest, többek között ezért alakították át a verzió kiadási és liszenszelési struktúrát.
A régi frissítési rendszert, ahol több évbe telt egy új verzió kiadása, leváltották egy féléves kiadási rendszerre, amelyben 3 évente adnak ki hosszútávon támogatott verziót (LTS verzió, Long Term Support). Így már egy előrelátható frissítési tervet kaptunk kézhez.
Emellett van még egy fontos változás: az Oracle 2019-től már nem biztosít ingyenes frissítést a kiadott verziókhoz. (Ezzel viszont előtérbe kerültek az olcsóbb – Azul Zulu JDK – vagy a teljesen ingyenes megoldások – OpenJDK . Ezek a megoldások szinte teljesen megegyeznek az Oracle JDK-val, csak nagyon kicsi és elhanyagolható mértékben térnek el).
Tapasztalatok alapján viszont hiába lépte meg a gyorsabb fejlesztési ciklust az Oracle, nagyon sok érintett még mindig a Java 8-nál ragadt.
Miért “nehéz” a Java verzió váltás?
Egy 2020-as felmérés alapján a professzionális fejlesztők körében még mindig 75% használ Java 8-at valamilyen projektben.
A „nehéz” váltásnak több oka is lehet.Egyrészt a Java applikációkat mindig hosszútávra tervezik. Másrészt pedig leginkább a pénzügyi és nagyvállalati szektorban elterjedt programozási nyelv, ahol a változás mindig kényelmetlen, főleg, ha egy jól megszokott, biztonságos rendszer megváltoztatásáról, frissítéséről van szó. Harmadrészt az Oracle, hogy ne kapjon túl nagy sokkot az ipar, a kiadási terv megváltoztatásánál egy elég sokáig tartó LTS támogatást kínál a Java 8-hoz (2030). A Java keretrendszerek és fejlesztési eszközök fejlesztőinek is fel kellett venniük a gyors iramot (sok nem támogatta még a Java 11-et az elején).
Viszont a felgyorsult technológiai trendek miatt ezek a cégek is előbb-utóbb lépéskényszerbe kerülnek.
Mivel általában hosszútávra készítünk egy Java programot, ezért ebben a cikkbencsak a Java 11 LTS verzióra váltással fogunk foglalkozni.
A 11-es verziót 2018 szeptemberében adták ki, és 2026-ig ad ki hozzá frissítéseket az Oracle (ezt követi a többi JDK megoldás is). A kiadása óta már jó pár CPU (critical patch update – kritikus javítás frissítés) kiadáson átesett, így már biztonsággal használható, a következő LTS verzió pedig csak ez év (2021) szeptemberében fog megjelenni.
Nézzük át, milyen előnyökkel is jár, ha átállunk Java 11-re.
A változás legfontosabb előnyei
Új alapértelmezett Garbage Collector (GC)
A GC röviden a Java takarítója, ő felel azért, hogy bizonyos időközönként eltakarítsa a „szemetet” a memóriából. A Java 11 alapértelmezett GC-je már a G1GC, ami a régi Parallel GC-hez képest nagy teljesítmény javulást okoz. A Java 8-at is át lehet állítani úgy, hogy a G1GC használja, viszont még így is, a Java 11 G1GC-je jön ki „győztesként”. Egy elég nagy ráncfelvarráson esett át, így közel 16%-os teljesítményjavulást okoz, ha a Java 8 manuálisan átírt G1GC-jéhez viszonyítjuk:
JDK modularitás docker környezetben
Java JDK9-es verziótól kezdve a JDK-t már modulárisan lehet kezelni. Ez annyit tesz, hogy nem muszáj az egész JDK-t használnunk, elég csak azt, ami szükséges az adott applikáció futtatásához. Ennek legnagyobb előnye a konténerizált világban van, hiszen a docker image elkészítésénél nem pakoljuk bele az egész JDK-t, hanem csak azt, amire tényleg szükség van. Így akár a docker image mérete 50-60%-kal csökkenhet (természetesen ez függ az applikációtól is, hogy mennyi mindenre van szüksége). Ez a méretcsökkenés egy felhőben futtatott környezetben sok megtakarított költséget is jelent.
Biztonsági fejlődés
Már támogatott a TLS 1.3 (Transport Layer Security) protokoll, ami nem csak biztonsági előrelépés, hanem teljesítménybeli javulást is okoz. Itt viszont fontos megjegyezni, hogy ezt az előnyt csak akkor tudjuk használni, ha a másik rendszer is támogatja a TLS 1.3-at, amivel kommunikálni szeretnénk ezen protokollon keresztül. (Sok fejlesztési keretrendszerben ez még nem valósult meg.)
Technológiai fejlődés
Persze, a fentieken felül, még sok más változás van a Java 8-hoz képest (például új String, Collection, File metódusok, Local-Variable Type-var), amikre most nem tértem ki bővebben. Ha érdekel az összes változás, itt tudjátok megnézni:
https://www.oracle.com/java/technologies/javase/9-all-relnotes.html
https://www.oracle.com/java/technologies/javase/10-relnote-issues.html
https://www.oracle.com/java/technologies/javase/11-relnote-issues.html
Azonban az jól látszódik, hogy a fejlődés felgyorsult és érdemes tartani az iramot, nehogy túl nagy szakadék legyen egy verzióváltásnál, ami már esetleg fájdalmasabb, időigényesebb és költségesebb váltást okozna.
Csináljuk, de hogyan?
Fontos egy jó, előre átgondolt tervet készíteni az adott projekthez arról, hogyan történjen az átállás és miket érinthet. Maga a Java 11-re váltás Java 8-ról nem okoz nagy refaktorizálást – természetesen ez azért függ a projekt szerkezétől is -, viszont szeretnénk egy-két dolgot megemlíteni, amivel a váltás során találkozhatunk.
Eltávolított modulok
A JDK 11-ben már nem szerepelnek a Java EE és Corba modulok. Ezek a modulok viszont könnyen behúzhatóak bármelyik dependencia kezelővel (pl. Maven).
Az eltávolított Java EE modulok:
- java.xml.ws: Java API for XML Web Services (JAX-WS) és SOAP with Attachments for Java (SAAJ)
- java.xml.bind: Java Architecture for XML Binding (JAXB)
java.xml.ws.annotation: Általános annotációk, amik a JAVA SE által kiajánlottak és a webszervíz kommunikációban segítenek - java.corba: CORBA modul
- java.transaction: Java Transaction API, ami a CORBA objektum tranzakció szervízét szolgálja ki
- java.activation: JavaBeans Activation Framework
- java.se.ee: alap modul, ami a fenti 6 modult szolgálja ki
TLS support
Mivel az alapérlemezett TLS protokoll már az 1.3, ezért, ha valahol a TLS protokollt használjuk (pl. egy sima https hívás), akkor meg kell vizsgálni, hogy a másik félnél (akivel akarunk kommunikálni ezen protokollon keresztül) támogatva van-e a TLS 1.3-as protokoll. Ha nincs, akkor vissza kell váltani az 1.2-es protokollra (például jvm beállítással: „-Dhttps.protocols=TLSv1.2 -Djdk.tls.client.protocols=TLSv1.2„)
Dependenciák
A Java váltásnál érdemes a depedenciák frissítését is beütemezni és ezt is előre megtervezni. Itt is lehetőleg minden függőségnél egy jól támogatott verzióra átállni. Előfordulhat olyan is, hogy egy régi függőség már nincs továbbfejlesztve, adott esetben nincs olyan verziója, ami támogatja a Java 11-et, ebben az esetben kell keresni helyett egy alternatívát.
Megéri Java 11-re váltani?
A váltás halogatása egyre inkább mélyíti a technológiai szakadékot és felhő környezetben akár jelentős többlet költségekkel járhat.
Valójában nem az a kérdés, hogy megéri-e váltani java 11-re, inkább az, hogy mikor.
Egy jó tervezéssel és például egy másik fejlesztési projekttel egybedolgozva nem okoz nagy többletmunkát egy Java verziófrissítés. Ha lehetőségünk adódik rá, tegyük meg a váltást, nehogy azon kapjunk magunkat, hogy a Java verziók és a fejlesztési technológia rég elhaladt mellettünk egy gyorsabb vágányon.
Ha elkél a segítség
Az Intalionnál 10. éve támogatjuk közép- és nagyvállalati ügyfeleinket rendszereik sikeres fejlesztésében és a naprakészen tartásában. Azt valljuk, nem szabad hagyni, hogy az IT szabjon gátat az üzleti fejlődésnek. Ezért, legyen szó szaktanácsadásról, projekt- vagy rendszertervezésről, komplett fejlesztési feladatokról vagy supportról, tapasztalt kollégáink megtalálják az adott igényekhez optimális megoldást.
