Hat hónapnyi fejlesztés után az Oracle bemutatta a Java SE 18 (Java Platform, Standard Edition 18) platformot, amelynek referencia megvalósítása az OpenJDK nyílt projekt. Kivéve néhány elavult lehetőség eltávolítását, a Java SE 18 megőrzi a visszafelé kompatibilitást a korábbi Java platform kiadásokkal — a régebbi Java projektek szinte változtatás nélkül is működnek az új verzió alatt. A Java SE 18 telepítésre kész változatai (JDK, JRE és Server JRE) elkészültek Linuxhoz (x86_64, AArch64), Windowshoz (x86_64) és macOS-hoz (x86_64, AArch64). Az OpenJDK keretében kifejlesztett Java 18 referenciamű teljes mértékben nyitott a GPLv2 licenc alatt, GNU ClassPath kivételekkel, amelyek lehetővé teszik a dinamikus kötést kereskedelmi termékekkel.
A Java SE 18 a normál támogatási ciklusú kiadások közé tartozik, frissítéseit a következő kiadásig fogják megjelentetni. Hosszú távú támogatási (LTS) ágként a Java SE 17-t kell használni, amelynek frissítéseit 2029-ig fogják kiadni. Emlékeztetünk rá, hogy a Java 10 kiadása óta a projekt új fejlesztési folyamatra váltott, amely rövidebb új kiadási ciklusokat jelent. Az új funkciók most már egy folyamatosan frissített master ágon fejlődnek, ahová a már kész változtatások bekerülnek, és amelyről hat havonta stabilizáló ágakat ágaznak el az új kiadásokhoz.
A Java 18 újításaiból kiemelhető:
- Alapértelmezés szerint az UTF-8 kódolás van aktiválva. A Java API-k, amelyek a karakterkódolás figyelembevételével szöveges adatokat dolgoznak fel, mostantól alapértelmezés szerint az UTF-8-at használják minden platformon, függetlenül a rendszerbeállításoktól és a megadott helyi beállításoktól. A régi viselkedés visszaállításához, amelyben a kódolás a rendszer helyi beállításaival összhangban kerül kiválasztásra, használható a „-Dfile.encoding=COMPAT” paraméter.
- A csomag tartalmazza a com.sun.net.httpserver-t, amely tartalmazza a jwebserver eszközt és egy könyvtári API-t, amely egyszerű http-szerver megvalósítást kínál statikus tartalom kiszolgálására (CGI és servlet-szerű kezelők nem támogatottak). A beépített http-szerver nem optimalizált munka terhelésekhez, és nem támogatja a hozzáférés-kezelést és az azonosítást, mivel főként fejlesztési folyamatok során történő prototípus-építésre, hibakeresésre és projektek tesztelésére van szánva.
- A JavaDoc-ban megvalósították a "@snippet" címke támogatását, amely lehetővé teszi a működő példák és kódfragmentumok beágyazását az API dokumentációba, amelyeket érvényességellenőrző, szintaxiskiemelő és IDE-vel való integrációs eszközökkel lehet alkalmazni.
- Újraírták a java.lang.reflect (Core Reflection) API megvalósítását, amely a metódusokkal, mezőkkel és osztályok konstruktorai információk megszerzésére, valamint az osztályok belső struktúrájához való hozzáférésre szolgál. Magának a java.lang.reflect API-nak a megvalósítása változatlan maradt, de most a java.lang.invoke modul által biztosított metódusdeszkiptoraikon (method handles) keresztül valósul meg, nem pedig bájt-generátorok alkalmazásával. Ez a változás lehetővé tette a java.lang.reflect és java.lang.invoke megvalósításainak egységesítését és karbantartásuk egyszerűsítését.
- Javasolták a Vector API harmadik előzetes megvalósítását, amely vektorszámítási funkcionalitást kínál, amelyet x86_64 és AArch64 processzorok vektoriális utasításaival valósítanak meg, lehetővé téve, hogy műveleteket egyszerre több értékre (SIMD) alkalmazzanak. Ezzel szemben a HotSpot JIT-compilerben rendelkezésre álló auto-vektorizáló képességekkel, az új API egyértelmű irányítást biztosít a vektorizálás felett a párhuzamos adatfeldolgozáshoz.
- Hozzáadtak egy SPI-interfészt (szolgáltató interfész) a gazdasítónevek feloldására, IP-címek, amely lehetővé teszi alternatív névfeloldók használatát a java.net.InetAddress-ben, amelyek nem kötődnek az operációs rendszer által kínált kezelőkhöz.
- Javaszolgáltatáson kívüli kódokkal és adatokkal való interakciót lehetővé tevő Foreign Function & Memory API második előzetes megvalósítása került bemutatásra. Az új API hatékonyan lehetővé teszi nem JVM-ben futó funkciók hívását és a JVM által nem kezelt memória elérését. Például külső megosztott könyvtárakból hívhat meg funkciókat, és elérheti a folyamat adatait anélkül, hogy JNI-t kellene használnia.
- Bevezetésre került a második kísérleti megvalósítása a minták szerinti illesztésnek a «switch» kifejezésekben, amely lehetővé teszi a «case» címkékben nem pontos értékek, hanem rugalmas minták használatát, amelyek egy sor értéket ölelnek fel, ami korábban terjedelmes «if...else» kifejezéseket követelt meg. Object o = 123L; String formatted = switch (o) { case Integer i -> String.format("int %d", i); case Long l -> String.format("long %d", l); case Double d -> String.format("double %f", d); case String s -> String.format("String %s", s); default -> o.toString(); };
- A finalizálási mechanizmust elavultnak nyilvánították, és ezt a jövőbeli kiadások egyikében le fogják tiltani, beleértve az ehhez kapcsolódó módszereket is, mint például Object.finalize(), Enum.finalize(), Runtime.runFinalization() és System.runFinalization().
- A ZGC (Z Garbage Collector), SerialGC és ParallelGC szemétgyűjtők támogatják a karakterláncok deduplikálását.
Forrás: opennet.ru
