A Java SE 16 kiadása

Hat hónapnyi fejlesztés után az Oracle kiadta a Java SE 16 (Java Platform, Standard Edition 16) platformot, amelynek referenciakivitelezése az OpenJDK nyílt projekt. A Java SE 16 megőrzi a visszafelé kompatibilitást a korábbi Java platformverziókkal, így minden korábban írt Java-projekt változtatás nélkül futtatható az új verzió alatt. Az installálásra kész Java SE 16 (JDK, JRE és Server JRE) buildjei elkészültek Linuxhoz (x86_64, AArch64), Windowshoz és macOS-hez. Az OpenJDK keretein belül fejlesztett Java 16 referenciakivitelezése teljesen nyílt a GPLv2 licenc alapján, GNU ClassPath kivételekkel, amelyek lehetővé teszik a kereskedelmi termékekkel való dinamikus kötést.

A Java SE 16 a normál támogatási időszakú kiadások közé tartozik, amelyhez frissítések a következő kiadásig érkeznek. A hosszú távú támogatási (LTS) ághoz a Java SE 11 használata javasolt, amelyhez frissítések 2026-ig lesznek elérhetők. A következő LTS-kiadás tervezett időpontja 2021 szeptember. Emlékeztetünk, hogy a Java 10 kiadása óta a projekt új fejlesztési folyamatra tért át, amely rövidebb új kiadásciklusokkal számol. Az új funkcionalitás most egy folyamatosan frissített master ágon fejlődik, amelybe a már elkészült változtatások kerülnek, és amelyből hat havonta stabilizáló ágak ágaznak le az új kiadásokhoz.

Az új kiadás előkészítése során a fejlesztés a Mercurial verziókezelő rendszerről a Git-re és a GitHub közös fejlesztési platformra átkerült. A migrációtól azt várják, hogy javítja a tárolóval végzett műveletek teljesítményét, növeli a tárolás hatékonyságát, biztosítja a projekt teljes történetében végzett változásokhoz való hozzáférést, javítja a kódellenőrzés támogatását és lehetővé teszi az API használatát a munkafolyamatok automatizálásához. Ezen túlmenően a Git és a GitHub alkalmazása a projektet vonzóbbá teszi a kezdők és a Git-hez szokott fejlesztők számára.

A Java 16 újdonságai közül kiemelhetők:

  • Hozzáadva egy kísérleti jdk.incubator.vector modul, amely a Vector API megvalósítását tartalmazza. Ez az API vektorizált számítási funkciókat biztosít, amelyek a x86_64 és AArch64 processzorok vektorizált utasításait használják, lehetővé téve, hogy egyszerre több értéket is feldolgozhassunk (SIMD). A HotSpot JIT-kompilátor által biztosított automatikus vektorizálási lehetőségekkel ellentétben az új API lehetőséget ad a vektorizálás kifejezett kezelésére az adatok párhuzamos feldolgozása érdekében.
  • A C++-ban írt JDK és HotSpot VM kódokban lehetőség van a C++14 specifikában megjelenő funkciók használatára. Korábban csak a C++98/03 szabványok voltak engedélyezve.
  • A ZGC (Z Garbage Collector), amely passzív módban működik és minimalizálja a szemétgyűjtés miatti késéseket, lehetővé tette a szálak veremének párhuzamos feldolgozását anélkül, hogy leállítaná az alkalmazás szálainak végrehajtását. A ZGC-nél mostantól csak a folyamatos késéseket okozó műveletek igénylik a működés leállítását, amelyek általában csak néhány száz mikrosecondig tartanak.
  • A SocketChannel, a ServerSocketChannel és a java.nio.channels osztályok Unix-sockets (AF_UNIX) támogatását kaptak.
  • Megvalósult egy Linux-disztribúció Alpine portja a musl standard C könyvtárral, amely népszerű a konténerizált, mikroszolgáltatás-alapú, felhő- és beágyazott rendszerek körében. A javasolt port lehetővé teszi, hogy a Java programokat normál alkalmazásokként futtassuk az ilyen környezetekben. Továbbá, a jlink révén eltávolíthatók az összes nem használt modul, és létrehozható egy minimális környezet, amely elegendő az alkalmazás futtatásához, ami lehetővé teszi a konkrét alkalmazásokhoz igazodó tömör képek létrehozását.
  • Megvalósult az Elastic Metaspace mechanizmus, amely optimalizálja a JVM HotSpot metadatalapú (metaspace) memóriafoglalási és visszaadási műveleteit. Az Elastic Metaspace használata csökkenti a memóriafragmentációt, csökkenti a class loader költségeit, és pozitív hatással van a hosszú ideig futó szerveralkalmazások teljesítményére azáltal, hogy a nem használt osztály metaadatokat gyorsabban adja vissza az operációs rendszernek. A class-ok eltávolítása utáni memóriafelszabadítási mód kiválasztásához a „-XX:MetaspaceReclaimPolicy=(balanced|aggressive|none)” opciót javasoljuk.
  • Hozzáadva a JDK port Windows rendszerű, AArch64 architektúrájú processzorokra épülő hardveren működő rendszerekhez.
  • Javasolták a Foreign-Memory Access API harmadik előzetes verzióját, amely lehetővé teszi a Java alkalmazások számára, hogy biztonságosan és hatékonyan férjenek hozzá Java heap-en kívüli memóriaterületekhez, új MemorySegment, MemoryAddress és MemoryLayout absztrakciók kezelésével.
  • Megvalósításra került egy kísérleti Foreign Linker API, amely lehetővé teszi a Java számára a natív kódhoz való hozzáférést. Az új Foreign-Memory API-val együtt ez a programozói interfész jelentősen leegyszerűsíti a hagyományos megosztott könyvtárak feletti kötések létrehozását.
  • Hozzáadva a jpackage segédeszköz, amely lehetővé teszi független (self-contained) Java alkalmazások csomagolását. Ez az eszköz a JavaFX-ből származó javapackager alapjaira épül, és lehetővé teszi csomagok létrehozását különböző platformok native formátumaiban (msi és exe Windowsra, pkg és dmg macOS-ra, deb és rpm Linuxra). A csomagok tartalmazzák az összes szükséges függőséget.
  • Alapértelmezés szerint bekapcsolásra került a JDK belső elemeinek szigorú kapszulázása, a kritikus API-k, mint például a sun.misc.Unsafe kivételével. Az "--illegal-access" opció értéke most alapértelmezetten "deny"-ra van állítva a "permit" helyett, ami a legtöbb belső osztály, módszer és mező elérésére irányuló kódbeli kísérletek blokkolását eredményezi. A korlátozás megkerüléséhez az "--illegal-access=permit" opció használható.
  • Stabilizálásra került az instanceof operátornál a mintázatillesztés megvalósítása, amely lehetővé teszi, hogy azonnal meghatározzuk a helyi változót a már ellenőrzött érték eléréséhez. Például az alábbiak szerint lehet írni: "if (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..}" anélkül, hogy kifejezetten meg kellene határozni "String s = (String) obj"-t. Régen: if (obj instanceof Group) { Group group = (Group) obj; var entries = group.getEntries(); } Most már meg lehet állni enélkül a definíció nélkül is: if (obj instanceof Group group) { var entries = group.getEntries(); }
  • Stabilizálásra került a "record" kulcsszó megvalósítása, amely kompakt formát kínál osztályok definiálásához, lehetővé téve a különböző alacsony szintű metódusok, mint például equals(), hashCode() és toString() explicit meghatározásának elkerülését, amikor az adatok csak mezőkben tárolódnak, és azokkal kapcsolatos működés nem változik. Ha egy osztályban típusos implementációkat használnak az equals(), hashCode() és toString() metódusokhoz, akkor ezek explicit meghatározása nélkül is el lehet kerülni: public record BankTransaction(LocalDate date, double amount, String description) {}

    Ez a hirdetés automatikus módon hozzáadja az equals(), hashCode() és toString() metódusok megvalósítását a konstruktorhoz és az adatmódosítást vezérlő metódusokhoz (getter).

  • Javasolták a második előzetes verziót a zárolt („sealed”) osztályok és interfészek számára, amelyeket más osztályok és interfészek nem használhatnak öröklésre, kibővítésre vagy a megvalósítás felülbírálására. A zárolt osztályok egy deklaratívabb módot kínálnak a szuperosztály használatának korlátozására, mint a hozzáférési módosítók, amelyek a kiterjesztésre engedélyezett alosztályok explicit felsorolásán alapulnak. package com.example.geometry; public sealed class Shape permits com.example.polar.Circle, com.example.quad.Rectangle, com.example.quad.simple.Square {…}

Forrás: opennet.ru

Megbízható hosting vásárlása weboldalak számára, DDoS védelemmel, VPS VDS szerverek. 🔥 Megbízható webtárhely vásárlása DDoS védelemmel, VPS VDS szerverek | ProHoster