Veröffentlichung von Java SE 24 und OpenJDK 24

Nach sechs Monaten Entwicklung hat Oracle die Plattform Java SE 24 (Java Platform, Standard Edition 24) veröffentlicht, deren Referenzimplementierung auf dem Open-Source-Projekt OpenJDK basiert. Abgesehen von der Entfernung einiger veralteter Funktionen bietet Java SE 24 Rückwärtskompatibilität zu früheren Versionen der Java-Plattform – die meisten zuvor geschriebenen Java-Projekte werden ohne Änderungen unter der neuen Version lauffähig sein. Installationsfertige Builds von Java SE 24 (JDK, JRE und Server JRE) sind für Linux (x86_64, AArch64), Windows (x86_64) und macOS (x86_64, AArch64) vorbereitet. Die im Rahmen des OpenJDK-Projekts entwickelte Referenzimplementierung von Java SE 24 ist vollständig unter der GPLv2-Lizenz mit Ausnahmen für GNU ClassPath lizenziert, die dynamisches Linking mit kommerziellen Produkten erlauben.

Java SE 24 gehört zur Kategorie der Releases mit normaler Unterstützung, für die Updates bis zur nächsten Version bereitgestellt werden. Für eine Version mit langfristiger Unterstützung (LTS) sollten Java SE 21 oder Java SE 17 verwendet werden, für die Updates bis 2031 bzw. 2029 veröffentlicht werden (öffentliche Updates bis 2028 und 2026). Die erweiterte Unterstützung für die LTS-Version Java SE 8 wird bis 2030 fortgesetzt, während Java SE 11 bis 2032 unterstützt wird. Die nächste LTS-Version wird die Herbstveröffentlichung von Java SE 25 sein.

Zu den Neuerungen in Java SE 24 gehören:

• Ein experimenteller generativer Modus für den Garbage Collector Shenandoah wurde vorgeschlagen, bei dem alte und neu erstellte Objekte getrennt verarbeitet werden, um die Effizienz der Bereinigung von Objekten mit kurzer Lebensdauer zu erhöhen. Der neue Modus bietet eine vorhersehbarere Durchsatzrate, Stabilität bei sich ändernden Lasten und eine Verringerung des Speicherverbrauchs während der Müllabfuhr. Der Scheduler von Shenandoah zielt darauf ab, die Ausfallzeiten während der Müllabfuhr durch die Durchführung größerer Arbeitsmengen parallel zur Ausführung von Java-Anwendungen zu reduzieren.
• In der HotSpot JVM wurde experimentelle Unterstützung für kompakte Objekt-Header implementiert, deren Größe auf 64-Bit-Systemen von 96 auf 64 Bit (von 12 auf 8 Byte) reduziert wurde. Die Verringerung der Header-Größe ermöglicht eine Reduzierung des Heap-Formats und erhöht die Cache-Effizienz.
• Im Garbage Collector G1 wurde die Implementierung der Barrieren vereinfacht, die den Zugriff von Anwendungen auf den Speicher überwachen. In der neuen Version wurden die Operationen zur Erweiterung der Barrieren auf einen späteren Kompilierungsschritt im C2 JIT verschoben. Durchgeführte Tests zeigen, dass diese Verschiebung die Overhead-Kosten im JIT-Compiler C2 je nach Anwendung um 10-20 % senken kann.
• Eine API für die Verwendung kryptografischer Schlüsselableitungsfunktionen (KDF, Key Derivation Function) wurde hinzugefügt, die es ermöglichen, zusätzliche Schlüssel der erforderlichen Länge auf der Basis eines geheimen Schlüssels (z. B. eines Passworts) und einer beliebigen Datenmenge zu generieren. Die KDF-API hat derzeit den Status einer Vorabversion (Preview).
• Es wurde die Möglichkeit zur vorausgreifenden (Ahead-of-Time) Lade- und Zusammenstellung von Klassen hinzugefügt. Diese Änderung beschleunigt den Start der HotSpot JVM, indem die im Anwendung verwendeten Klassen bereits in einem geladenen und zusammengestellten Zustand bereitgestellt werden. Bei der ersten Ausführung der Anwendung wird der Zustand aller Klassen im Cache gespeichert und bei nachfolgenden Starts zur Beschleunigung des Ladevorgangs verwendet.
• Eine API Class-File für das Parsen, Generieren und Konvertieren von Java-Klassen-Dateien wurde hinzugefügt.

  ClassFile cf = ClassFile.of(); ClassModel classModel = cf.parse(bytes); byte[] newBytes = cf.build(classModel.thisClass().asSymbol(), classBuilder -> { for (ClassElement ce : classModel) { if (!(ce instanceof MethodModel mm && mm.methodName().stringValue().startsWith("debug"))) { classBuilder.with(ce); } } });

• Eine erweiterte API Stream wurde hinzugefügt, die die Definition benutzerdefinierter Zwischenoperationen unterstützt, die in Fällen nützlich sein können, in denen die vorhandenen eingebauten Zwischenoperationen nicht ausreichen, um die gewünschten Datenkonvertierungen durchzuführen. Benutzerdefinierte Handler werden über die neue Zwischenoperation Stream::gather(Gatherer) angeschlossen, die die Elemente des Streams verarbeitet und den angegebenen benutzerdefinierten Handler anwendet. jshell > Stream.of(1,2,3,4,5,6,7,8,9).gather(new WindowFixed(3)).toList() $1 == > [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
• Es wurde eine vierte vorläufige Implementierung der Scoped Values vorgeschlagen, die eine gemeinsame Nutzung unveränderlicher Daten in Threads ermöglichen und einen effizienten Datenaustausch zwischen untergeordneten Threads gewährleisten (Werte werden vererbt). Scoped Values entwickeln sich als Ersatz für das Mechanismus der thread-lokalen Variablen und sind effizienter im Einsatz von sehr vielen virtuellen Threads (Tausende und Millionen von Threads). Der Hauptunterschied zwischen Scoped Values und thread-lokalen Variablen besteht darin, dass erstere einmal geschrieben werden, danach nicht mehr verändert werden können und nur zur Laufzeit des Threads verfügbar bleiben.
• In die Musterabgleichmechanismen wurde eine vorläufige Unterstützung für die Verwendung primitiver Typen (int, byte, char und andere grundlegende Typen, die keine Objekte sind) in allen Arten von Vorlagen, im ‚instanceof‘ Operator und in ‚switch‘ Blöcken hinzugefügt. switch (x.getStatus()) { case 0 -> "okay"; case 1 -> "warning"; case 2 -> "error"; case int i -> "unbekannter Status: " + i; } if (i instanceof byte b) { … b … }
• Eine neunte vorläufige Implementierung der Vector API wurde vorgeschlagen, die Funktionen für vektorielle Berechnungen bereitstellt, die unter Verwendung von Vektor-Instruktionen der Prozessoren x86_64 und AArch64 ausgeführt werden und es ermöglichen, Operationen gleichzeitig auf mehrere Werte anzuwenden (SIMD). Im Gegensatz zu den im JIT-Compiler HotSpot angebotenen Möglichkeiten zur Auto-Vektorisierung von skalaren Operationen, ermöglicht die neue API eine explizite Steuerung der Vektorisierung für die parallele Datenverarbeitung.
• Die Unterstützung für die Synchronisierung virtueller Threads ohne deren Anheftung (Pinning) an plattformgebundene Threads wurde implementiert. Virtuelle Threads in einem synchronisierten Methoden- oder Ausdrucksb locking Zustand geben nun ihren Plattform-Thread frei, sodass andere virtuelle Threads ihn nutzen können, was die Anzahl der verfügbaren virtuellen Threads erheblich erhöht und die Skalierbarkeit von Anwendungen, die Multithreading verwenden, verbessert.
• Es wurde eine dritte vorläufige Variante der Möglichkeit hinzugefügt, Ausdrücke in Konstruktoren vor dem Aufruf von super(...) anzugeben, der für den expliziten Aufruf des Konstruktors der Elternklasse aus dem Konstruktor der abgeleiteten Klasse verwendet wird, sofern diese Ausdrücke nicht auf die vom Konstruktor erstellte Instanz verweisen. class Outer { void hello() { System.out.println("Hello"); } class Inner { Inner() { hello(); super(); } } }
• Die jlink-Utility unterstützt jetzt die Erstellung von Laufzeit-Abbildern ohne die Verwendung von JMOD-Dateien, was die Größe des JDK um etwa 25 % reduziert.
• Eine zweite vorläufige Variante zur Verwendung eines Ausdruks "import module M" wurde hinzugefügt, um alle von dem angegebenen Modul exportierten Pakete auf einmal zu importieren. Diese Änderung erleichtert die Wiederverwendung von Modulbibliotheken erheblich, da Bibliotheken und Klassen ohne Angabe ihres Standorts in der Pakethierarchie eingebunden werden können. Zum Beispiel führt die Angabe "import module java.base" zum Import aller 54 Pakete, die im Modul java.base enthalten sind, die zuvor einzeln erwähnt werden mussten ("import java.io.*", "import java.util.*" usw.).
• Eine vierte vorläufige Implementierung von implizit deklarierten Klassen und anonymen Instanzen der Methode "main" wurde hinzugefügt, bei der auf Deklarationen von public/static, die Übergabe eines Argumentarrays und andere mit der Klassendeklaration verbundene Entitäten verzichtet werden kann. // früher war public class HelloWorld { public static void main(String[] args) { System.out.println("Hello world!"); } } // jetzt ist es möglich void main() { System.out.println("Hello, World!"); }
• Ein vierter vorläufiger Entwurf der API für strukturierte Parallelität (Structured Concurrency) wurde zur Erprobung vorgeschlagen. Diese API vereinfacht die Entwicklung von Multithread-Anwendungen, indem sie mehrere Aufgaben, die in verschiedenen Threads ausgeführt werden, als einen einzelnen Block behandelt.
• Die APIs KeyPairGenerator, Signature und KeyFactory unterstützen jetzt die Algorithmen ML-KEM (CRYSTALS-Kyber) und ML-DSA (CRYSTALS-Dilithium), die vom National Institute of Standards and Technology (NIST) standardisiert wurden und quantensicher sind. Diese Algorithmen nutzen kryptographische Methoden, die auf der Lösung von Gittertheorie-Problemen basieren, deren Lösungszeit sich auf herkömmlichen und quantencomputern nicht unterscheidet.
• Im Garbage Collector ZGC wurde die Unterstützung des nicht-generativen Modus entfernt, der die Verarbeitung von "alten" und "jungen" Objekten nicht trennt. Ab Java SE 23 wird der generative Modus von ZGC standardmäßig angewendet.
• Es wurden Warnungen bei der Verwendung der JNI (Java Native Interface) und FFM (Foreign Function & Memory) APIs hinzugefügt, um Entwickler auf die bevorstehende Einschränkung des Zugriffs auf diese APIs vorzubereiten, da in einer der kommenden Versionen der Integritätsmodus aktiviert wird, der standardmäßig die Interaktion mit nativem Code verbietet.
• Es wurde eine Warnung aktiviert, wenn auf Methoden zum Zugriff auf externen Speicher (außerhalb der JVM) zugegriffen wird, die von der Klasse sun.misc.Unsafe bereitgestellt werden. Für den Zugriff auf Off-Heap-Speicher und die Interaktion mit externem Code wird empfohlen, die VarHandle-API zu verwenden. In der vorherigen Version wurde die Unterstützung von sun.misc.Unsafe als veraltet gekennzeichnet.
• Der Security Manager wurde deaktiviert, der seit langem veraltet war und nach der Einstellung der Unterstützung für das Browser-Plugin nicht mehr benötigt wird. Der Security Manager wurde in Java 17 als veraltet eingestuft. In einer der kommenden Versionen ist geplant, den Security Manager vollständig zu entfernen.
• DerCode zur Unterstützung der 32-Bit-Plattform von Windows auf x86-Systemen wurde entfernt. Der Port für 32-Bit x86-Systeme wurde als veraltet erklärt und die Unterstützung für Linux auf 32-Bit x86-Systemen wird eingestellt.

Zusätzlich kann die Veröffentlichung eines Updates der Plattform für die Erstellung von JavaFX-Anwendungen 24 sowie die neue Version der universellen GraalVM hervorgehoben werden, die die Ausführung von Anwendungen in JavaScript (Node.js), Python, Ruby, R und allen Sprachen für die JVM (Java, Scala, Clojure, Kotlin) sowie in Sprachen, die LLVM-Bitcode erzeugen können (C, C++, Rust) unterstützt. Neben der Unterstützung von JDK 24 wurden in der neuen GraalVM-Version Optimierungen für Aufgaben im Zusammenhang mit maschinellem Lernen vorgenommen, die Unterstützung für die Kompilierung von Java-Bytecode in Maschinencode verbessert und ein Mechanismus namens SkipFlow hinzugefügt, um die Größe der ausführbaren Dateien zu reduzieren und die Kompilierzeit zu verkürzen.

Quelle: opennet.ru