Hat hónapnyi fejlesztés után az Oracle kiadta a Java SE 27-öt (Java Platform, Standard Edition 27), amely a nyílt forráskódú OpenJDK projektet használja referenciaként. Néhány elavult funkció eltávolításától eltekintve a Java SE 27 visszafelé kompatibilis a Java platform korábbi kiadásaival – a legtöbb korábban írt Java projekt változatlanul fut az új verzió alatt. A Java SE 27 telepítésre kész buildjei (JDK, JRE és Server JRE) elő vannak készítve a következőkre: Linux (x86_64, AArch64), Windows (x86_64) és macOS (x86_64, AArch64). Az OpenJDK projekt által fejlesztett Java SE 27 referencia implementáció teljesen nyílt forráskódú a GPLv2 licenc alatt, a GNU ClassPath kivétellel, amely lehetővé teszi a dinamikus összekapcsolást a kereskedelmi termékekkel.
A Java SE 27-ot normál támogatású kiadásként kategorizálták, a frissítések a következő kiadásig jelennek meg. A hosszú távú támogatás (LTS) ág a Java SE 25, Java SE 21 vagy Java SE 17, a frissítések 2033-ig, 2031-ig és 2029-ig jelennek meg (általánosan elérhetők 2030, 2028 és 2026 szeptemberéig). A Java SE 8 LTS ág kiterjesztett támogatása 2030-ig, a Java SE 11-é pedig 2032-ig folytatódik.
A Java SE 27 (1, 2, 3, 4) verziójában bekövetkezett változások a következők:
- Alapértelmezés szerint minden környezet a G1 (Garbage-First) szemétgyűjtőt használja, amelyet korábban szerverrendszerekhez használtak. A G1 nagy memóriakapacitású többprocesszoros rendszereken való használatra, valamint a kiszámítható késleltetés és a nagy átviteli sebesség egyensúlyozására van optimalizálva. Működés közben a G1 sok kis régióra osztja a memóriát, és prioritást élveznek azok a régiók, amelyek több nem használt objektummal és kevésbé aktívan hozzáfért adatokkal rendelkeznek.
- A HotSpot JVM alapértelmezés szerint kompakt objektumfejléceket használ. 64 bites rendszereken a fejléc mérete 96-ról 64 bitre csökkent, ami csökkenti a memóriafogyasztást és növeli az adatok processzor gyorsítótárába kerülésének valószínűségét. A SPECjbb2015 benchmarkokban a memóriafogyasztás 22%-kal, a CPU-terhelés 8%-kal, a szemétgyűjtési műveletek száma pedig 15%-kal csökkent. A JSON-elemző tesztfutási ideje 10%-kal csökkent.
- A TLS 1.3 implementáció támogatást nyújt a hibrid kulcs-egyeztetési sémákhoz, amelyek a kvantumrezisztens ML-KEM (CRYSTALS-Kyber) algoritmust kombinálják a klasszikus ECDHE elliptikus görbe algoritmusokkal: X25519MLKEM768 (ECDHE az X25519 görbével + ML-KEM-768), SecP256r1MLKEM76 (ECDHE a secp256r1 görbével + ML-KEM-768), és SecP384r1MLKEM1024 (ECDHE a secp384r1 görbével + ML-KEM-1024). A javax.net API-ban.ssl Ezek a sémák alapértelmezés szerint engedélyezve vannak, és használatukhoz nem szükséges semmilyen alkalmazásmódosítás.
- A JDK Flight Recorder (JFR), egy teljesítményfigyelésre, profilalkotásra és diagnosztikára használt eszköz, mostantól támogatja a parancssori argumentumok, a környezeti változók kezdeti értékeinek és a mentett diagnosztikai információkban található rendszertulajdonságok fertőtlenítését. Ez a módosítás megakadályozza a profilozott folyamat által feldolgozott érzékeny adatok, például a környezeti változókon keresztül átadott engedélyezési tokenek és API hozzáférési kulcsok kiszivárgását.
- A Lazy Constants API harmadik előzetese elkészült, amely lehetővé teszi a JVM-ben konstansként kezelt, megváltoztathatatlan adatokat tartalmazó objektumokkal való munkát. Az ilyen objektumokra a "final" kulcsszóval rendelkező mezőkhöz hasonló teljesítményoptimalizálások vonatkoznak. A "final" kulcsszóval ellentétben az új API elválasztja a konstans értékek létrehozását az inicializálásuktól, garantálja, hogy egy érték csak egyszer inicializálható, csökkenti a programindítási időt, és lehetővé teszi a korábban csak a JDK belső kódjában használt konstans hajtogatási optimalizálások felhasználói kódban való használatát. class Application { // Korábban: // static final UserService USERS = new UserService(); // Most: static final StableValue FELHASZNÁLÓK = StableValue.of(); public static FelhasználóiSzolgáltatás felhasználók() { return FELHASZNÁLÓK.orElseSet(FelhasználóiSzolgáltatás::new); } }
- A mintaillesztő motor bevezeti a primitív típusok (int, byte, char és más nem objektum alapú típusok) használatának ötödik változatát mindenféle mintában, az instanceof operátorban és a switch blokkokban. switch (x.getStatus()) { case 0 -> "okay"; case 1 -> "warning"; case 2 -> "error"; case int i -> "unknown status: " + i; } if (i instanceof byte b) { … b … }
- A Structured Concurrency API hetedik tervezete tesztelésre megjelent, amely leegyszerűsíti a többszálú alkalmazások fejlesztését azáltal, hogy a különböző szálakon futó több feladatot egyetlen egységként kezeli.
- A Vector API tizenkettedik tesztimplementációja elkészült. Ez az API függvényeket biztosít az x86_64 és AArch64 processzor vektor utasításaival végrehajtott vektorszámításokhoz, és lehetővé teszi több értékkel végzett egyidejű műveleteket (SIMD). A HotSpot JIT fordító skaláris műveletek automatikus vektorizálásával ellentétben az új API explicit módon szabályozza a vektorizálást a párhuzamos adatfeldolgozás során.
- Az API harmadik tervezete már elérhető a kriptográfiai kulcsokat, tanúsítványokat és tanúsítvány-visszavonási listákat tartalmazó objektumok PEM (Privacy-Enhanced Mail) formátumú kódolásához és dekódolásához.
Emellett örömmel jelentjük be a JavaFX 27 platform frissítésének kiadását, amely grafikus felhasználói felületű alkalmazások létrehozására szolgál. A GraalVM 27 univerzális virtuális gép megjelenése is várhatóan a következő órákban jelenik meg, amely támogatja az alkalmazások futtatását JavaScriptben (Node.js), Pythonban, Rubyban, R-ben, bármilyen JVM nyelven (Java, Scala, Clojure, Kotlin), valamint olyan nyelveken, amelyekhez LLVM bitkód generálható (C, C++, Rust).
Forrás: opennet.ru
