2021. szeptember 14-én indult a Java 17 Java nyelvi és futási platform hosszú távú támogatási (LTS) verziója. Ismerjük meg a Java 17 újdonságait, és érdemes-e frissíteni.
Sok alkalmazás a Java régebbi verzióit használja, beleértve a Java korábbi LTS verzióit: Java 11 és Java 8.
Miért érdemes a vállalkozásoknak a legújabb Java verzióra frissíteni? A frissítés erre Java 17 erőfeszítést igényel, főként a JVM-en belüli új szolgáltatások és funkciók maximális kihasználása érdekében.
Sok vállalkozás használja a Docker és Docker lemezképeket, hogy könnyedén, minimális erőfeszítéssel és idővel váltson át a Java 17-re. A fejlesztők meghatározhatják folyamatos integrációs/telepítési (CI/CD) folyamataikat, és mindent Docker lemezképekben futtathatnak. Ez nem érinti a régebbi Java-verziókat használó többi csapatot, mivel használhatják a régi Docker-képfájlokat.
Tartalomjegyzék
JAVA 17 Jellemzők
macOS és AArch64 támogatás
Az ehhez a verzióhoz hozzáadott egyik kritikus JVM-funkció a macOS támogatásának javítása az AArch64 architektúrán a JEP 391 használatával. Támogatni fogja a processzorok legújabb sorozatát (M1), amelyet az Apple az elmúlt évben adott ki számítógépeihez.
Ez nem feltétlenül nagy baj az ilyen platformokon használó felhasználók számára, mivel egyes gyártók olyan JDK-verziókat indítottak el, amelyek támogatják ezt az architektúrát, és akár vissza is adják a támogatást a Java 8-tól kezdve. A hivatalos jóváhagyási pecsét azonban elengedhetetlen a jövőbeli karbantartás és támogatás biztosításához. a felhsználói felület. Összehasonlításképpen, a Linux/AArch64 platform támogatása a Java 9-hez, a Windows/AArch64 pedig a Java 16-hoz került.
Lezárt osztályok
A Sealed Classes egy olyan szolgáltatás, amelyet a Java 17-ben vezettek be. A lezárt osztályok funkció befejezte próbafázisát, és a Java 17 hivatalos platformja és nyelve lett. Lehetővé teszi a fejlesztők számára, hogy meghatározzák a típus megengedett altípusait, és megakadályozzák, hogy mások nem szándékosan bővítsék vagy hajtsák végre.
A lezárt osztályok azt is lehetővé teszik a fordító számára, hogy fordítás közben hibákat generáljon, amikor megkísérel egy lezáratlan típust nem engedélyezett altípussá konvertálni. A Java 17 új renderelési folyamatot is hoz az AWT/Swing alkalmazásokhoz, amelyek macOS-en futnak az Apple Metal API-t használva OpenGL helyett. Továbbfejlesztett API-val és továbbfejlesztett funkciókkal rendelkezik a véletlen számok generálásához.
Változások, törlések és korlátozások a Java 17-ben
A Java 17 számos változtatást, törlést és új korlátozást is tartalmaz.
JDK belső elemek tokozása
Az egyik változás a JDK Internals beágyazási folyamatának lezárása. Az első alkalom, hogy ezt a Java 9-ben vezették be, és futás közben figyelmeztetést adott, amikor a felhasználó reflektálást vagy hasonlót próbált meg megkerülni a belső API-k használatára vonatkozó szokásos korlátozásokat. A viselkedés szabályozására parancssori argumentumokat is hozzáadtak.
A Java 9-től kezdve különféle API-k jöttek létre, amelyek egységes módot kínálnak a leggyakrabban használt feladatok elvégzésére; a felhasználók ezeket az API-kat belsőleg használnák. A Java 16 esetében az alapértelmezett figyelmeztetésről a kivételek kidobásához való hozzáférés letiltására módosult. A viselkedés megváltoztatásához azonban a parancssori argumentumot használja.
Java 17 esetén a parancssori argumentum megszűnik, és ez a korlátozás deaktiválható. Ez azt jelenti, hogy ezen belső API-khoz való minden jogosulatlan hozzáférés védett.
Mindig szigorú lebegőpontos szemantika
Egy további „eltávolítás” az Always-Strict Floating Point szemantika újbóli bevezetéseként írható le. A Java 1.2 módosította a Java lebegőpontos szemantikai alapértelmezését, amely lehetővé teszi a JVM számára, hogy a teljesítmény javítása érdekében kis pontossággal kereskedjen a lebegőpontos számításokban. Azokban az osztályokban és metódusokban, ahol szigorú szemantikát kellett használni, egy strictfp kulcsszó került hozzáadásra. Azóta különféle típusú utasításkészleteket vezettek be a CPU-kba, így a szigorú lebegőpontos szemantika felesleges költségek nélkül használható. Az alapértelmezett vagy szigorú szemantika megvalósításának szükségessége megszűnt.
A Java 17 eltávolítja a korábbi alapértelmezett szemantikát, és minden lebegőpontos műveletet szigorúan hajt végre. A strictfpi kifejezés még mindig jelen van. Ennek azonban nincs hatása, és fordításkor figyelmeztetést ad.
Idő előtti (AOT) összeállítás
A Java 9 kísérleti funkcióként vezette be az idő előtti (AOT) fordítást, amely a Graal fordítót használja, és Java segítségével JIT kódot írtak. A Java 10 a JVMCI interfész beépítésével a Graal fordítót JIT fordítóként használhatóvá tette az OpenJDK-ban. Mióta megjelent, hatalmas fejlődésen ment keresztül. A Graal fordító hatalmas fejlődésen ment keresztül, és a JVM-et GraalVM néven kapta.
RMI aktiválás
Az RMI aktiválása megszűnt JEP 407 a Java 8-ból való eltávolítását követően, végül elavult, és a Java 15-ön belüli eltávolítás követelményeként lett megjelölve. Az RMI aktiválása olyan módszert biztosított, amely lehetővé tette az elosztott objektumok igény szerinti erőforrásait az RMI segítségével. Azonban minimális volt a használat, és jobb alternatíva is elérhető a jelenben. Az RMI fennmaradó részére nincs hatással az aktiválási rész eltávolítása.
Applet API eltávolítása
Az Applet API-t végre kijelölte eltávolításra JEP 398Az Applet API lehetőséget biztosított a Java AWT/Swing vezérlők integrálására a böngészőn belüli weboldalakba. Ezt azonban egyetlen modern böngésző sem támogatja, ami azt jelenti, hogy a kisalkalmazások az elmúlt évtizedben gyakorlatilag elérhetetlenek voltak.
Biztonsági vezető
A leglényegesebb lejáratás az, hogy a biztonsági menedzser ( JEP 411). A Security Manager egy ideje használatban van a Java 1.0 óta. Úgy tervezték, hogy korlátozza a Java helyi műveleteit a gépen, például korlátozza a hálózatokhoz, fájlokhoz és egyéb hálózati erőforrásokhoz való hozzáférést. Megpróbálja a nem megbízható kódot is homokozóba helyezni a tükrözés és az adott API-k blokkolásával.
A Security Manager vége a Java 12-ben kezdődött. Egy parancssori argumentum került hozzáadásra, amely blokkolja a biztonságkezelő használatát futás közben. A Java 17-ben végrehajtott változtatás azt jelenti, hogy a rendszer futásidejű figyelmeztetést generál a JVM-ben, amikor megpróbál beállítani egy Security Managert, akár parancssorból, akár dinamikusan futás közben.
Inkubátor és előnézeti funkciók
Sokan kíváncsiak voltak, hogy a Java 17 rendelkezik-e előnézeti és inkubátorfunkciókkal, tekintettel arra, hogy a Java 17-et hosszú távon támogatott verzióként hirdették meg. A Java 17 két inkubátor modullal és egy előnézeti funkcióval rendelkezik!
Vector API
Vector API ( JEP 414) jelenleg az inkubátor második fázisában tart. Az API lehetővé teszi a fejlesztők számára, hogy meghatározzák a vektorszámítást, amelyet a JIT fordító ezután a JVM által futtatott CPU architektúra által támogatott megfelelő vektorutasítássá alakít át (például az SSE vagy AVX utasításkészletek használatával).
Korábban a fejlesztőknek skaláris függvényeket kellett használniuk, vagy a platformra jellemző natív könyvtárakat kellett létrehozniuk. A Vector API Java-ban való megvalósítása egy zökkenőmentes tartalék mechanizmust is biztosít, amely a korábbi verziókban bonyolult volt.
A Vector API szabványosítása lehetővé teszi a JDK-n belüli osztályok számára a használatát. A Java Arrays mismatch() metódusai módosíthatók úgy, hogy inkább Java-n futtassák, így nem kell több platform-specifikus implementációt karbantartani és írni a JVM-en belül.
Foreign Function & Memory API
Egy további inkubátorfunkció az úgynevezett Foreign Function & Memory API ( JEP 412). Ez a Java 16 két másik inkubátormoduljának evolúciója és egyesítése, a The Foreign Linker API ( JEP 389) és Foreign-Memory API ( JEP 393). Mindkettő hozzáférést biztosít a natív memóriához és a kódhoz Java nyelven írt statikusan tipizált programozással.
Mintaillesztés a kapcsolóhoz
A Java 17 nyelvi előnézetének utolsó funkciója a Pattern Matching for Switch ( JEP 406). Ez a nyelvi szolgáltatás típus szerint bővíti a switch kifejezéseket és utasításokat, hasonlóan a mintaillesztésnél használt szintaxishoz (JEP 394), amely a Java 16-tal szabványossá vált.
Korábban, ha különböző műveleteket akart végrehajtani egy objektum dinamikus természete alapján, akkor egy if-else láncot kellett létrehoznia az ellenőrzések egy példányával, például:
String type(Object o) {
if (o instanceof List) {
return "A List of things.";
}
else if (o instanceof Map) {
return "A Map! It has keys and values.";
}
else if (o instanceof String) {
return "This is a string.";
}
else {
return "This is something else.";
}
}
A kapcsoló kifejezés és a kapcsolók új mintaillesztési funkciójának kombinálásával a folyamat a következőhöz hasonlóra redukálható:
String type(Object o) {
return switch (o) {
case List l -> "A List of things.";
case Map m -> "A Map! It has keys and values.";
case String s -> "This is a string.";
default -> "This is something else.";
};
}
Amint azt észrevehette, az ellenőrzés folyamatában van egy változó deklarációja. A Pattern többi változójához hasonlóan a példány egyeztetése azt jelzi, hogy ezt az objektumot típusellenőrzéssel és öntéssel végezték, és elérhető a változóból az aktuális területén.
Az előnézeti funkció egy újabb lépés a mintaillesztés felé. A következő lépés a tömbök és rekordok dekonstruálásának képessége.
Frissítsen Java 17-re?
Igen, folyamatosan frissítenie kell a legújabb verzióra, de nem az első napon. Előfordulhat, hogy a használt szoftvert és könyvtárakat nem frissítették a Java 17-tel való kompatibilitás érdekében, ezért előfordulhat, hogy várnia kell egy ideig, amíg elkészül.
Ha elakad a Java LTS-verziójával, például a Java 8-mal vagy a Java 11-el, a nyelven és magán a JVM-en belül számos lehetőség van, amelyek frissítést igényelnek a Java 17-ig. Mivel ez egy hosszú távú karbantartási kiadás, van nagy esély van rá, hogy az éles környezeted is Java 17-re frissül.
Ha egy teljesen új projektbe kezd, vagy éppen készül a projektje a Java 17-re, valószínűleg a Java 17-re való átállás a leghatékonyabb megoldás, mivel csökkenti a költözés költségeit. Ez azt is lehetővé teszi a projekten dolgozó fejlesztők számára, hogy kihasználják az összes legújabb funkciót és a műveleti oldalt.
Kihasználhatja az elmúlt néhány évben történt számos fejlesztést, például a Java-n futó konténerek továbbfejlesztett támogatását, valamint az új, alacsony késleltetésű szemétgyűjtő-megvalósításokat.