{"id":143670,"date":"2025-09-17T11:12:01","date_gmt":"2025-09-17T09:12:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-java-se-25-lts-i-openjdk-25"},"modified":"2025-09-17T11:12:01","modified_gmt":"2025-09-17T09:12:01","slug":"vypusk-java-se-25-lts-i-openjdk-25","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/vypusk-java-se-25-lts-i-openjdk-25","title":{"rendered":"Ver\u00f6ffentlichung von Java SE 25 LTS und OpenJDK 25","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nach sechs Monaten Entwicklung hat Oracle die Plattform Java SE 25 (Java Platform, Standard Edition 24) ver\u00f6ffentlicht, f\u00fcr die das Open-Source-Projekt OpenJDK als Referenzimplementierung dient. Abgesehen von der Entfernung einiger veralteter Funktionen in Java SE 25 bleibt die Abw\u00e4rtskompatibilit\u00e4t zu fr\u00fcheren Versionen der Java-Plattform erhalten \u2013 die meisten zuvor geschriebenen Java-Projekte werden ohne \u00c4nderungen unter der neuen Version lauff\u00e4hig sein. Installierbare Builds von Java SE 25 (JDK, JRE und Server JRE) sind f\u00fcr Linux (x86_64, AArch64), Windows (x86_64) und macOS (x86_64, AArch64) verf\u00fcgbar. Die im Rahmen des OpenJDK-Projekts entwickelte Referenzimplementierung von Java SE 25 ist vollst\u00e4ndig unter der GPLv2-Lizenz mit Ausnahmen von GNU ClassPath lizenziert, die das dynamische Binden an kommerzielle Produkte erm\u00f6glichen. <\/p>\n
Java SE 25 geh\u00f6rt zu den Versionen mit verl\u00e4ngertem Supportzeitraum, f\u00fcr die Updates bis 2033 ver\u00f6ffentlicht werden (\u00f6ffentlich zug\u00e4ngliche Updates werden bis September 2030 erscheinen). Auch die Versionen Java SE 17 und 21 werden als LTS-Zweige weiterhin unterst\u00fctzt, mit Updates, die bis 2029 und 2031 erscheinen (\u00f6ffentlich zug\u00e4nglich \u2013 bis 2026 und 2028). Der erweiterte Support f\u00fcr die LTS-Zweige Java SE 8 und 11 wird bis 2030 und 2032 fortgesetzt. <\/p>\n
Unter den Neuerungen in Java SE 25 (1, 2, 3, 4): <\/p>\n
\n
Eine experimentelle API StableValue wurde hinzugef\u00fcgt, um mit Objekten zu arbeiten, die unver\u00e4nderliche Daten enthalten und in der JVM als Konstanten verarbeitet werden. F\u00fcr solche Objekte gelten Leistungsoptimierungen, die denen von Feldern mit dem Schl\u00fcsselwort \u201efinal\u201c \u00e4hnlich sind. Die API StableValue trennt die Erstellung von konstanten Werten von deren Initialisierung, garantiert, dass ein Wert nur einmal initialisiert werden kann, verk\u00fcrzt die Startzeit von Programmen und erm\u00f6glicht es, in Benutzer-Code Konstantenfaltung (constant-folding) anzuwenden, die zuvor nur im internen Code des JDK verwendet wurde. class Application { \/\/ War: \/\/ static final UserService USERS = new UserService(); \/\/ Ist: static final StableValue USERS = StableValue.of(); public static UserService users() { return USERS.orElseSet(UserService::new); } }\n
Eine experimentelle API zur Kodierung und Dekodierung von Objekten mit kryptographischen Schl\u00fcsseln, Zertifikaten und Widerrufsllisten wurde hinzugef\u00fcgt, die das PEM-Format (Pivacy-Enhanced Mail) verwendet.\n
Unterst\u00fctzung f\u00fcr Scoped Values wurde hinzugef\u00fcgt, die es erm\u00f6glichen, unver\u00e4nderliche Daten in Threads gemeinsam zu nutzen und effizient Daten zwischen untergeordneten Threads auszutauschen (Werte werden vererbt). Scoped Values entwickeln sich weiter, um den Mechanismus der Thread-lokalen Variablen zu ersetzen und sind bei der Verwendung einer sehr gro\u00dfen Anzahl virtueller Threads (tausende und Millionen von Threads) effizienter. Der Hauptunterschied zwischen Scoped Values und thread-lokalen Variablen besteht darin, dass erstere einmal geschrieben werden, danach nicht mehr ge\u00e4ndert werden k\u00f6nnen und nur zur Laufzeit des Threads verf\u00fcgbar bleiben.\n
Eine API zur Verwendung von kryptografischen Schl\u00fcsselableitungsfunktionen (KDF, key derivation function) wurde hinzugef\u00fcgt, die es erm\u00f6glichen, zus\u00e4tzliche Schl\u00fcssel der erforderlichen L\u00e4nge auf der Grundlage eines geheimen Schl\u00fcssels (z. B. eines Passworts) und einer beliebigen Datensammlung zu generieren.\n
Der Code und die Build-Skripte zur Unterst\u00fctzung von 32-Bit-x86-Systemen wurden entfernt. Die Abschaffung der Unterst\u00fctzung f\u00fcr 32-Bit-x86-Systeme hat es erm\u00f6glicht, die Infrastruktur f\u00fcr das Build- und Testen des JDK zu vereinfachen und Funktionen zu implementieren, die auf Plattformen angewiesen sind, ohne Fallback-Handler f\u00fcr 32-Bit-x86-Systeme erstellen zu m\u00fcssen.\n
Die M\u00f6glichkeit, den Ausdruck \u201eimport module M\u201c zu verwenden, um sofort alle Pakete zu importieren, die von dem angegebenen Modul exportiert werden, wurde hinzugef\u00fcgt. Diese \u00c4nderung vereinfacht erheblich die Wiederverwendung von Modulbibliotheken und erm\u00f6glicht das Einbinden von Bibliotheken und Klassen, ohne deren Platz in der Paket-Hierarchie festlegen zu m\u00fcssen. Zum Beispiel f\u00fchrt die Angabe \u201eimport module java.base\u201c zum Import aller 54 Pakete, die im Modul java.base enthalten sind und zuvor einzeln erw\u00e4hnt werden mussten (zum Beispiel \u201eimport java.io.*\u201c, \u201eimport java.util.*\u201c usw.).\n
Eine kompakte Art der Programmgestaltung wurde vorgeschlagen, die sich als n\u00fctzlich f\u00fcr das Lernen und bei der Entwicklung kleiner Anwendungen erweisen kann. In kompakter Form ist keine Definition zus\u00e4tzlicher Klassen erforderlich, g\u00e4ngige APIs werden automatisch importiert und es stehen vereinfachte Ein-\/Ausgabemethoden zur Verf\u00fcgung. Zum Beispiel kann die Anwendung \u201eHello, World!\u201c auf Folgendes reduziert werden: void main() { IO.println(\u201eHello, World!\u201c); }\n
Es ist nun erlaubt, Ausdr\u00fccke in Konstruktoren vor dem Aufruf von super(\u2026), der verwendet wird, um den Konstruktor der Elternklasse explizit aus dem Konstruktor der abgeleiteten Klasse aufzurufen, anzugeben, solange diese Ausdr\u00fccke nicht auf die vom Konstruktor erstellte Instanz verweisen. class Outer { void hello() { System.out.println(\u201eHello\u201c); } class Inner { Inner() { hello(); super(); } } }\n
Der generative Modus des Shenandoah-Garbage-Collectors wurde hinzugef\u00fcgt, bei dem alte und neu erstellte Objekte getrennt verarbeitet werden, um die Effizienz der Bereinigung von Objekten mit kurzer Lebensdauer zu erh\u00f6hen. Der neue Modus sorgt f\u00fcr eine vorhersehbarere Durchsatzrate, Widerstandsf\u00e4higkeit gegen\u00fcber Last\u00e4nderungen und eine Reduktion des Speicherverbrauchs beim Garbage-Collection. Der Shenandoah-Planer zielt darauf ab, die Stop-Zeit w\u00e4hrend der Garbage-Collection zu reduzieren, indem er einen gr\u00f6\u00dferen Arbeitsumfang parallel zur Ausf\u00fchrung von Java-Anwendungen durchf\u00fchrt.\n
Die Erstellung eines Caches f\u00fcr die vorzeitige (Ahead-of-Time) Lade- und Verkn\u00fcpfung von Klassen wurde vereinfacht, was den Start der HotSpot JVM beschleunigt, indem Klassen im bereits geladenen und verkn\u00fcpften Zustand verwendet werden. Beim Start sind keine separaten Operationen mehr erforderlich, um die Aktivit\u00e4t zu protokollieren und einen Cache zu erstellen, sondern es gen\u00fcgt ein einziger Befehl: java -XX:AOTCacheOutput=app.aot -cp app.jar com.example.App \u2026\n
Bei der Start der HotSpot-Java-VM wurde die M\u00f6glichkeit implementiert, Ausf\u00fchrungsprofile von Methoden zu verwenden, die beim vorherigen Start der Anwendung ermittelt wurden. Diese \u00c4nderung erm\u00f6glicht es dem JIT-Compiler, auf die Sammlung von Statistiken zu verzichten und sofort damit zu beginnen, nativen Code zu generieren, ohne auf die Erstellung des Profils warten zu m\u00fcssen.\n
In der HotSpot-JVM wurde die Unterst\u00fctzung f\u00fcr kompakte Objektheader implementiert, deren Gr\u00f6\u00dfe unter 64-Bit-Systemen von 96 auf 64 Bit (von 12 auf 8 Byte) reduziert wurde. Die Verkleinerung der Header-Gr\u00f6\u00dfe erm\u00f6glicht eine Reduzierung der Heap-Gr\u00f6\u00dfe und steigert die Effizienz des Caches.\n
Es wurde eine Testimplementierung der Vector-API vorgeschlagen, die Funktionen f\u00fcr Vektorcomputing bereitstellt, die unter Verwendung von Vektoranweisungen der Prozessoren x86_64 und AArch64 ausgef\u00fchrt werden und es erm\u00f6glichen, Operationen gleichzeitig auf mehrere Werte (SIMD) anzuwenden. Im Gegensatz zu den im JIT-Compiler HotSpot angebotenen M\u00f6glichkeiten zur automatischen Vektorierung von Skalarkoperationen bietet die neue API die M\u00f6glichkeit, die Vektorisierung explizit f\u00fcr die parallele Datenverarbeitung zu steuern.\n
F\u00fcr Tests wurde die f\u00fcnfte Vorabversion der API f\u00fcr strukturierten Parallelismus (Structured Concurrency) vorgeschlagen, die die Entwicklung multithreaded Anwendungen erleichtert, indem mehrere Aufgaben, die in verschiedenen Threads ausgef\u00fchrt werden, als ein einzelner Block bearbeitet werden.\n
Im Muster\u00fcbereinstimmungsmechanismus wurde ein dritter vorl\u00e4ufiger Vorschlag zur M\u00f6glichkeit der Verwendung primitiver Typen (int, byte, char und andere grundlegende Typen, die keine Objekte sind) in allen Arten von Vorlagen, im Operator \u201einstanceof\u201c und in \u201eswitch\u201c-Bl\u00f6cken unterbreitet. switch (x.getStatus()) { case 0 -> \u201eokay\u201c; case 1 -> \u201ewarnung\u201c; case 2 -> \u201efehler\u201c; case int i -> \u201eunbekannter status: \u201e + i; } if (i instanceof byte b) { \u2026 b \u2026 }\n
Im JDK Flight Recorder (JFR) wurde die experimentelle Unterst\u00fctzung f\u00fcr das Profiling mit einer genaueren Verfolgung des CPU-Ressourcenverbrauchs auf der Linux-Plattform hinzugef\u00fcgt. Ausf\u00fchrungszeitinformationen verschiedener Konstruktionen k\u00f6nnen anschaulich mit Hilfe von farbigen Diagrammen «FlameGraph» visualisiert werden.\n
Die Stabilit\u00e4t des JDK Flight Recorder (JFR) beim asynchronen Sampling von Java-Thread-Stacks wurde durch die Umgehung des Aufrufstapels nur an «sicheren Punkten» (safepoints) verbessert.\n
Im JDK Flight Recorder (JFR) wurden Werkzeuge zur R\u00fcckverfolgung und Bewertung der Ausf\u00fchrungszeit von Methoden hinzugef\u00fcgt. Die R\u00fcckverfolgung des Aufrufstapels spezifischer Methoden und die Erfassung pr\u00e4ziser Statistiken \u00fcber Methodenaufrufe, einschlie\u00dflich Metriken wie Ausf\u00fchrungszeit und Anzahl der Aufrufe, werden unterst\u00fctzt. <\/ul>\n