fbpx

Java 9 újdonságai – 1. rész

Java 9 megjelenési dátuma

A Java 9 aktuális tervezett kiadási dátuma 2017. szeptember 21. Vagyis itt van a nyakunkon. Elég zűrös Java verzióról van szó, ami a határidőket illeti, ugyanis nem egyszer lett elhalasztva a kiadás dátuma. Ez talán nem is olyan meglepő, ha megnézzük, hogy milyen új feature-ök kerültek bele. Az elkövetkezendő blog posztokban sorra vesszük a leglényegesebb újdonságokat.

Java 9 oktatás az A&K Akadémián

Hogy lehet az, hogy mi már ezt a verziót oktatjuk, amikor még meg sem jelent?

A végleges hivatalos verzió még valóban nem jelent meg, de az early access (EA) verzió már egy ideje elérhető, amely mivel már túl vagyunk a feature complete dátumon, az összes feature-t tartalmazza, ami a végleges verzióban is benne lesz.

Be kell vallanom, hogy nagy mázlista vagy, ha most kezded el a Java-t tanulni, mert az egyik feature – a jshell – nagyban segíti az oktatást és a tanulást, főleg a kezdeti lépéseknél, mert nagyon szemléletes eszköz. De erről részletesen majd egy kicsit később. Először akadna itt egy kis játék…

A Java Platform modul rendszere (Jigsaw) – bevezető

Java 9 - Project JigsawA Java 9 legmeghatározóbb eleme a Project Jigsaw néven futó, a Java modularizációját célzó projekt, amely a többszöri release date csúsztatásért felelős.

Én személy szerint nem bánom, sőt, örülök is neki, hogy a projekt fejlesztése során tartott mérföldköveknél őszintén képesek voltak a projekt aktuális állapotára objektíven tekinteni, és azt mondani, hogy ez így nem elég jó.

Mint tudjuk, a Java nyelvnél erősen koncentrálnak a készítők a visszafele kompatibilitásra, vagyis hogy az új Java verziók, amennyire csak lehet, a korábbi verzióval fordított bájtkódot módosítás nélkül futtatni tudják. Persze ez nem volt mindig tartható.

A modularizáció megoldása a Java nyelv jövőjét tekintve esszenciális feladat. Ami most a Java 9-ben a nyelv részévé válik, az ezentúl mindig szerves részét fogja képezni, radikális módosítások eszközölése jelentős problémákat vetne fel. De úgy tűnik, hogy most már hamarosan tényleg lezárják ezt az alprojektet és az éles kiadás részét fogja képezni.

Miről is szól a Java Platform modul rendszere?

Eddig is volt lehetőség megírt kódunk alap szintű szervezésére. Ha arra gondolunk, hogy megírt osztályainkat már most is külön fájlokban tároljuk, illetve ezeket a fájlokat tudjuk csoportosítani mappákba, vagyis csomagokba (package-ekbe).

A modul rendszer lényege, hogy még egy absztrakciós szinttel kiegészítse ezt a csoportosítás.

Miért jó nekünk még egy absztrakciós szint?

Az alapvető probléma a Java nyelv hozzáférés módosítók limitált képességeiből adódik. Mindannyian ismerjük a public, protected, private és package private scope-okat. A public elérhetőségű osztályaink jelentik itt a problémát, ezek publikus metódusai ugyanis a publikus API-nk részét képezik, és ezáltal bármilyen más osztályból elérhetők. Ez a Java nyelv létrejötte óta hatalmas gubancokat okozott már a komplex rendszereknél, ugyanis amit a nyelv megenged, azt bizony a leleményes programozók ki is használják. Így történt ez ennél a nyelvi feature-nél is, ami átláthatatlan, szövevényes, spagetti kódot eredményezett. A spagetti kódnak súlyos hátrányai vannak.

JAR – JAR

A Java 9 előtt lényegében az egyetlen módszerünk az enkapszulációra a JAR-ok voltak. A JAR – vagyis Java ARchive – a programunk lefordított változatának egy ZIP fájlba tömörített változata, amit néhány metainformációval elláthattunk, mint például, hogy melyik osztály main metódusa a belépési pont. Ha például Java-ban JSON adatstruktúrákat szerettünk volna használni, akkor letöltöttük a megfelelő JAR fájlt, amiben minden osztály benne volt a JSON-ök kezeléséhez. Természetesen kedvünkre választhattunk az implementációk közül, mert több csapat is fejleszt saját JSON kezelőt.

Ezek után persze a programunk már csak ezen JSON kezelő JAR jelenlétében működőképes, amikor kiadjuk éles rendszerünket, akkor ezt a JAR-t se szabad elfelejtenünk.

Érdekesség

A „jar” egy angol főnév is, ami többek között dunsztos üveget jelent, amiben a lekvárt is eltesszük. A JAR elnevezés valószínűleg innen is kapta a nevét, csak mi nem lekvárt, hanem lefordított Java osztályokat teszünk el benne.

Dunsztos üvegek… dunsztos üvegek mindenütt!

Egy nagy rendszer esetén természetesen nem csak egy ilyen külső library-tól való függőségünk van, hanem több, illetve tovább bonyolítja a helyzetet, hogy egy külső library maga is lehet, hogy egy másik library-t igényel a működéséhez. Ezeket a függőségeket, más szóval dependenciákat, feloldani sokszor nem triviális feladat.

Eddig mi tévők lehettünk a JAR-ok támadása ellen?

Ennek kezelésére eddig a modern build toolok adtak elegáns megoldást, mint a Maven és a Gradle. Ezeknél a tooloknál ugyanis egy központi repository-ban számon tartják az összes publikus library (artifact) összes publikusan elérhető verzióját azok függőségeivel együtt. Ez lehetőséget biztosít számunka a build tool használata során, hogy csak azt tüntessük fel, hogy a mi aktuális projektünknek milyen külső library-kra van szüksége, és a dependenciák feloldását már maga a tool végezze. Ez azt jelenti, hogy ha például a JSON kezelő library függ egy dátum kezelő library-tól, akkor ha mi a saját projektünknél megjelöljük, hogy a JSON kezelő library-ra szükségünk van, akkor a tool automatikusan felderíti a függőségi láncolatot és feloldja a függőségeket, vagyis ebben az esetben letölti a projektünkhöz a dátum kezelő library-t is, ezzel működőképessé téve a projektünket. A JAR-ok önmagukban ezt a függőséget nem képesek kifejezni.

Ezt a súlyos problémát orvosolja a Java Platform modul rendszere, amelyről a következő blog posztban olvashatsz.