A Java platform 9-11-es kiadása idején bejelentett nagy horderejű változások meglehetősen közismertek – modularitás, önálló JRE megszüntetése, Oracle Java fizetőssé tétele. Mindhárom körülmény olyan, ami fejtörést, vagy inkább fejfájást okoz azoknak a nagyvállalati szoftverüzemeltetőknek, akiknek feladata volna naprakész, biztonságos JRE-t, Java Runtime Environmentet biztosítani a felhasználóknak. A közelmúltban bemutattam, hogyan lehet felmérni a Java-használatot/igényt, most viszont egy megoldást mutatok arra, hogyan oldható meg a biztonságos JRE biztosítása.

Szűk mezsgyén kell egyensúlyoznunk

A Java 8-as vagy korábbi verziók esetében a mozgásterünk meglehetősen korlátozott. Az Oracle Java ugyanis nem egyezik meg az Open Javával, ezért egy Oracle Java JRE-vel megfelelően működő szoftver Open Java JRE a alatt másképpen fog viselkedni. Ennek ellenére, és feltéve hogy nincs szükség terméktámogatásra, csak frissítésekre, mindenképpen érdemes megkísérelni az átállást Open Javára, például az Amazon Corretto, az AdoptOpenJDK vagy a Bellsoft Liberica csomag valamelyikére, hiszen ha a szoftverek működésében nincs gond, elkerülhető az Oracle Java-támogatás tetemes költsége.  Hogy mennyire is életképes az Open Java, mutatja az is, hogy egy nagyobb, Magyarországon is jelenlévő bank a licencelési változásokat úgy követte le, hogy a Java 8-alapú netbank alkalmazása mellé már Open Java környezetet biztosít.

(Zárójelben megjegyzem: ideiglenesen megoldást jelenthet az is, ha korábbi, még ingyenes verzión tartjuk a Java-környezetünket, de emiatt idővel egyre nagyobb csörtéket kell majd vívni az informatikai biztonság felelőseivel.)

Az Open Java újabb, nevezetesen 11-es, LTS támogatottságú verzió esetében már jobbak a kilátásaink kompatibilitás terén is. Az Open JDK lett a Java Standard Edition (SE) platform referencia implementációja (értsd: minden más Java disztribúció, beleértve az Oracle Javát, is erre épül). Nyilván megoldást jelent, ha minden eszközünkre komplett JDK-t terítünk, de ettől kifinomultabb megoldás is létezik.

Itt jön a képbe a már említett modularitás és a jlink. A Java 9-es kiadása óta meglévő jlink lehetővé teszi, hogy az általunk választott modulokból egyedi futtatókörnyezetet készítsünk, ami a szükséges modulok mellett tartalmazza JVM-et is.

Ez elsősorban a fejlesztőknek létrehozott eszköz, amit a Java 14-es kiadásában kiegészítettek a natív telepítőkészletet létrehozó jpackage-dzsel. Ennek segítségével kompakt futtatókörnyezetet tudunk az alkalmazás mellé csomagolni. Így már nem a végfelhasználó terhe lesz a futtatókörnyezet beszerzése és naprakészen tartása.

A lehetőségek: fogjunk neki

Két lehetőségünk van. Minden Javát használó szoftverhez egyedi runtime-ot generálunk – ez nyilván a fejlesztő feladata volna. Ha ő nem teszi meg, vagy pótolhatjuk ezt a hiányosságot, vagy – és az a másik lehetőség – készítünk egy olyan runtime-ot, amiben benne van minden olyan modul, amire egy átlagos szoftver futtatására szükség lehet, és uniformizálhatjuk a környezetünkben terítendő futtatókörnyezetet. A jlink gyakorlatilag leválasztja a kiválasztott modulokat a JDK-ról.

Előbbi megoldás esetében először ki kell listázni a csomag függőségeit a jdeps segítségével, például ha van java környezeti változó beállítva, akkor jdeps -s c:\Útvonal\A\Fájlhoz.jar (nem kötelező a jar, helyette class-t is használhatunk).

Összehasonlításképp, ha kilistázzuk a telepített JDK moduljait (java --list-modules), látható, hogy mennyi, e szoftver szempontjából "felesleges" modul is található benne.

A függőségek ismeretében készíthetjük el a saját JRE-t jlinkkel: jlink --output C:\Útvonal\A\Leendő\Jrehez --add-modules előbb,listázott,modulok.

Elkészült a JRE, ami már nyugodtan használható azzal a szoftverrel, amelynek függőségeit megvizsgáltuk. Ha szükséges vagy kívánatos a minél kisebb méret, akkor fenti parancsot kiegészíthetjük a --no-header-files --no-man-pages --strip-debug opciókkal, további, esetünkben szükségtelen fájloktól könnyíthetjük meg a JRE-t. (Fontos: szoftverfejlesztői oldalról a jlink nem így használandó.)

Ha univerzálisabb megoldásra lenne szükség, lehetőség van a jlinknek megadni a “java.se” modult, ami minden alapmodult tartalmazni fog, így képes kiszolgálni a Javát használó szoftverek jelentős részét.
 

A java.se modul tartalma, azaz függőségei, melyek importálásra kerülnek. Forrás: Oracle (Kattintson a képre a nagyobb méretért)

Nem vagyunk teljesen magunkra utalva, ha JRE-re van szükségünk. Például a Bellsoft (amely a Java platform fejlesztésében jelentős szerepet vállal) ingyenesen készít JRE csomagokat a fent vázolthoz hasonló módon, akár openjfx-szel együtt csomagolva. Ilyen lehetőséget még az Oracle JDK-ban sem találunk, lévén az kikerült a standard modulok közül. De, annak ellenére, hogy a moduláris rendszer bevezetésével elvileg ütött az önálló JRE utolsó órája, ha szükségünk van rá, a Bellsoft, a Red Hat vagy más disztrubútor révén mégis lehet naprakész, biztonságos – és nem mellesleg ingyenes – JRE-nk újabb Java verziókra is.
 

Licencelési kérdések nem merülnek fel. Az így elkészített, illetve letöltött JRE mappáján belül a használt modulok licencei megtalálhatók a /legal mappában. De ami ennél is fontosabb, hogy ott van a Classpath Exceptionre vonatkozó engedély: ha tehát csak meghívjuk a JRE-t szoftverek futtatásához, nem érvényesül a GPL virális hatása.

A JRE használatával tárhelybéli előnyhöz jutunk a JDK-val szemben, hiszen például a Corretto 11 majd 300 megabájtos méretéhez képest az egyedi/Libreica JRE mérete 40 megabyte és 160 megabájt között mozog (utóbbi már tartalmazza az OpenJavaFX-et!). A valódi mögöttes elképzelés a modularitás bevezetésekor valószínűleg ehhez kapcsolódhatott – moduláris futtatókörnyezetekkel hatékonyabb, kisebb méretű docker képek hozhatók létre.

Értelemszerűen hosszú távon jobban járhatunk, ha a Java alkotói szándékainak megfelelve nem one-size-fits-all JRE-ket terítünk, hanem az alkalmazásfejlesztőtől várjuk el a jlink használatát és a szükséges modulok és a JVM szállítását.