Veröffentlichung von Java SE 24 und OpenJDK 24

Nach sechs Monaten Entwicklungszeit hat Oracle die Plattform Java SE 24 (Java Platform, Standard Edition 24) veröffentlicht, bei der das Open-Source-Projekt OpenJDK als Referenzimplementierung verwendet wird. Abgesehen von der Entfernung einiger veralteter Funktionen bleibt die Rückwärtskompatibilität mit früheren Versionen der Java-Plattform in Java SE 24 erhalten — die meisten zuvor entwickelten Java-Projekte werden ohne Änderungen unter der neuen Version weiterhin funktionieren. 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) verfügbar. Die im Rahmen des OpenJDK-Projekts entwickelte Referenzimplementierung von Java SE 24 ist vollständig unter der GPLv2-Lizenz mit Ausnahmen von GNU ClassPath veröffentlicht, die dynamisches Linking mit kommerziellen Produkten erlauben.

Java SE 24 gehört zur Kategorie der Versionen mit regulärem Support, für die Updates bis zur nächsten Veröffentlichung bereitgestellt werden. Als Version mit langfristigem Support (LTS) sollten Java SE 21 oder Java SE 17 verwendet werden, für die Updates bis 2031 bzw. 2029 bereitgestellt werden (öffentlich bis 2028 bzw. 2026). Die erweiterte Unterstützung der LTS-Version Java SE 8 läuft bis 2030, während Java SE 11 bis 2032 unterstützt wird. Die nächste LTS-Version wird das Herbst-Release von Java SE 25 sein.

Zu den Neuerungen in Java SE 24 gehören:

• Ein experimenteller generativer Modus für den Shenandoah-Garbage-Collector wurde vorgeschlagen, bei dem alte und neu erstellte Objekte separat verarbeitet werden, um die Effizienz der Bereinigung von Objekten mit kurzer Lebensdauer zu erhöhen. Der neue Modus bietet eine vorhersehbarere Durchsatzrate, Belastbarkeit bei wechselnden Lasten und verringerten Speicherverbrauch während der Garbage Collection. Der Shenandoah-Planer zielt darauf ab, die Ausfallzeiten während der Garbage Collection zu minimieren, indem er einen größeren Teil der Arbeit parallel zur Ausführung von Java-Anwendungen durchführt.
• In HotSpot JVM wurde experimentelle Unterstützung für kompakte Objektüberschriften implementiert, deren Größe auf 64-Bit-Systemen von 96 auf 64 Bit (von 12 auf 8 Byte) reduziert wurde. Die Verringerung der Überschriftengröße ermöglicht eine Reduzierung der Heap-Größe und steigert die Effizienz des Caches.
• Im G1 Garbage Collector wurde die Implementierung von Barrieren, die den Zugriff der Anwendung auf den Speicher überwachen, vereinfacht. In der neuen Version wurden die Barriererweiterungsoperationen auf einen späteren Kompilierungszeitpunkt im C2 JIT verschoben. Die durchgeführten Tests zeigen, dass dieser Transfer die Overheads im C2 JIT-Compiler um 10-20% senken kann, abhängig von der Anwendung.
• Eine API zur Nutzung kryptografischer Schlüsselableitungsfunktionen (KDF, key derivation function) wurde hinzugefügt, die es ermöglicht, zusätzliche Schlüssel der erforderlichen Länge auf Basis eines geheimen Schlüssels (z. B. eines Passworts) und einer beliebigen Menge von Daten zu generieren. Die KDF API hat derzeit den Status Vorschau (preview).
• Die Möglichkeit zur vorausschauenden (Ahead-of-Time) Laden und Zusammensetzung von Klassen wurde hinzugefügt. Diese Änderung ermöglicht einen schnelleren Start der HotSpot JVM, indem die in der Anwendung verwendeten Klassen bereits in einem geladenen und zusammengesetzten Zustand bereitgestellt werden. Beim ersten Start der Anwendung wird der Zustand aller Klassen im Cache zurückgesetzt und bei nachfolgenden Starts zur Beschleunigung des Ladevorgangs verwendet.
• Ein API für Class-File zum Parsen, Generieren und Konvertieren von Java-Klassendateien 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 Stream-API 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 Datenumwandlungen zu erreichen. Benutzerdefinierte Handler werden über die neue Zwischenoperation Stream::gather(Gatherer) verbunden, die die Stream-Elemente verarbeitet und den angegebenen Benutzer-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]]
• Die vierte vorläufige Implementierung von Scoped Values ermöglicht den gemeinsamen Gebrauch unveränderlicher Daten in Streams und den effizienten Datenaustausch zwischen untergeordneten Threads (Werte werden vererbt). Scoped Values entwickeln sich als Ersatz für den Mechanismus der thread-lokalen Variablen und sind bei der Nutzung einer sehr großen Anzahl virtueller Threads (Tausende bis Millionen) effizienter. 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 sind.
• In die Musterabgleichmechanismen wurde eine vorläufige Unterstützung für die Verwendung von primitiven 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 -> "unknown status: " + i; } if (i instanceof byte b) { … b … }
• Die neunte vorläufige Implementierung der Vector-API wurde eingeführt, die Funktionen für vektorielle Berechnungen bereitstellt, die unter Verwendung von Vektor-Anweisungen der x86_64- und AArch64-Prozessoren durchgeführt werden. Diese ermöglichen es, Operationen gleichzeitig auf mehrere Werte anzuwenden (SIMD). Im Gegensatz zu den im JIT-Compiler HotSpot verfügbaren Auto-Vektorisierungsfunktionen für skalare Operationen bietet die neue API die Möglichkeit, die Vektorisierung für die parallele Datenverarbeitung ausdrücklich zu steuern.
• Die Unterstützung für die Synchronisierung virtueller Threads ohne deren Anheftung (Pinning) an plattformgebundene Threads wurde implementiert. Virtuelle Threads in synchronisierten Methoden oder Ausdrücken im Zustand der Blockierung geben nun ihren plattformgebundenen Thread frei, wodurch anderen virtuellen Threads die Nutzung ermöglicht wird. Dies erhöht erheblich die Anzahl der verfügbaren virtuellen Threads und verbessert die Skalierbarkeit von Anwendungen, die Multithreading nutzen.
• Eine dritte vorläufige Möglichkeit wurde hinzugefügt, die die Angabe in den Ausdruckskonstrukteuren vor dem Aufruf von super(...) erlaubt, das für den expliziten Aufruf des Konstruktors der übergeordneten Klasse 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("Hallo"); } class Inner { Inner() { hello(); super(); } } }
• Das Tool jlink unterstützt jetzt die Erstellung von Laufzeit-Images ohne Verwendung von JMOD-Dateien, was die Größe des JDK um etwa 25 % reduziert.
• Eine zweite vorläufige Möglichkeit zur Verwendung des Ausdrucks „import module M“ wurde hinzugefügt, um sofort alle von dem angegebenen Modul exportierten Pakete zu importieren. Diese Änderung vereinfacht die Wiederverwendung von Modulbibliotheken erheblich, indem sie das Hinzufügen von Bibliotheken und Klassen ohne Angabe ihres Standorts in der Paket-Hierarchie ermöglicht. So führt beispielsweise 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.).
• Es wurde eine vierte Vorabversion von implizit deklarierten Klassen und anonymen Instanzen der Methode „main“ hinzugefügt, bei denen auf die Deklarationen von public/static, die Übergabe von Argumentarrays und andere mit der Klassendeklaration verbundene Entitäten verzichtet werden kann.// vorher public class HelloWorld { public static void main(String[] args) { System.out.println("Hello world!"); } }// jetzt möglich void main() { System.out.println("Hello, World!"); }
• Ein vierter Vorabversion des APIs für strukturierten Parallelismus (Structured Concurrency) wurde zu Testzwecken vorgeschlagen, der die Entwicklung von Multithreading-Anwendungen vereinfacht, indem er mehrere Aufgaben, die in unterschiedlichen Threads ausgeführt werden, als einen einzigen Block behandelt.
• Die APIs KeyPairGenerator, Signature und KeyFactory haben die Unterstützung für die Algorithmen ML-KEM (CRYSTALS-Kyber) und ML-DSA (CRYSTALS-Dilithium) erhalten, die vom National Institute of Standards and Technology (NIST) standardisiert und gegenüber Quantencomputern widerstandsfähig sind. Diese Algorithmen nutzen kryptographische Verfahren, die auf der Lösung von Problemen der Gittertheorie basieren, deren Lösungszeiten sich auf gewöhnlichen und Quantencomputern nicht unterscheiden.
• Im ZGC-Garbage Collector wurde die Unterstützung des nicht-generativen Betriebsmodus entfernt, der die Verarbeitung von "alten" und "jungen" Objekten nicht trennt. Ab Java SE 23 wird der generative ZGC-Modus standardmäßig verwendet.
• Warnmeldungen über die Nutzung der JNI-API (Java Native Interface) und FFM (Foreign Function & Memory) wurden hinzugefügt, um Entwickler auf die bevorstehenden Einschränkungen des Zugriffs auf diese APIs vorzubereiten, die in einer der zukünftigen Versionen durch den Activitätsmodus zur Gewährleistung der Integrität, der standardmäßig die Interaktion mit nativen Code verbietet, eingeführt werden.
• Eine Warnmeldung wird angezeigt, wenn auf Methoden zugegriffen wird, die externen Speicher (außerhalb der JVM) über die Klasse sun.misc.Unsafe bereitstellen. Für den Zugriff auf Speicher außerhalb des Heaps (off-heap) und die Interaktion mit externem Code wird empfohlen, die API VarHandle zu verwenden. In der vorherigen Version wurde die Unterstützung von sun.misc.Unsafe als veraltet erklärt.
• Der Security Manager wurde deaktiviert, da er seit langer Zeit nicht mehr relevant ist 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 markiert. In einer der nächsten Versionen ist geplant, den Code des Security Managers vollständig zu entfernen.
• Der Code zur Unterstützung der 32-Bit-Plattform des Betriebssystems Windows auf x86-Systemen wurde entfernt. Die Java-Portierung für 32-Bit-x86-Systeme wurde als veraltet erklärt und ist für die Abschaltung geplant (die Unterstützung von Linux auf 32-Bit-x86-Systemen wird eingestellt).

Zusätzlich wird die Veröffentlichung des Plattform-Updates für die Entwicklung von Anwendungen mit der grafischen Benutzeroberfläche JavaFX 24 und die neue Version der universellen virtuellen Maschine GraalVM erwähnt, die die Ausführung von Anwendungen in JavaScript (Node.js), Python, Ruby, R sowie in allen JVM-Sprachen (Java, Scala, Clojure, Kotlin) und in Sprachen, für die LLVM-Bitcode generiert werden kann (C, C++, Rust), unterstützt. Neben der Unterstützung von JDK 24 wurden in der neuen GraalVM-Version Optimierungen für machine learning-relevante Aufgaben durchgeführt, die Unterstützung der Kompilierung von Java-Bytecode in Maschinencode verbessert, ein SkipFlow-Mechanismus zur Reduzierung der Größe ausführbarer Dateien und zur Verkürzung der Kompilierungszeit hinzugefügt.

Quelle: opennet.ru