{"id":165062,"date":"2026-03-17T23:11:55","date_gmt":"2026-03-17T21:11:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-java-se-26-i-openjdk-26-proekt-po-integraczii-podderzhki-javascript-i-python-v-jvm"},"modified":"2026-03-17T23:11:55","modified_gmt":"2026-03-17T21:11:55","slug":"vypusk-java-se-26-i-openjdk-26-proekt-po-integraczii-podderzhki-javascript-i-python-v-jvm","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/vypusk-java-se-26-i-openjdk-26-proekt-po-integraczii-podderzhki-javascript-i-python-v-jvm","title":{"rendered":"Ver\u00f6ffentlichung von Java SE 26 und OpenJDK 26. Projekt zur Integration von Unterst\u00fctzung f\u00fcr JavaScript und Python in die JVM.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nach sechs Monaten Entwicklung hat Oracle die Plattform Java SE 26 (Java Platform, Standard Edition 26) ver\u00f6ffentlicht, deren Referenzimplementierung auf dem OpenJDK-Projekt basiert. Abgesehen von der Entfernung einiger veralteter Funktionen bleibt Java SE 26 mit fr\u00fcheren Versionen der Java-Plattform r\u00fcckw\u00e4rtskompatibel \u2013 die meisten zuvor geschriebenen Java-Projekte werden ohne \u00c4nderungen unter der neuen Version lauff\u00e4hig sein. Installierbare Builds von Java SE 26 (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 26 ist vollst\u00e4ndig unter der GPLv2-Lizenz mit Ausnahmen von GNU ClassPath lizenziert, die dynamisches Binden an kommerzielle Produkte erlauben. <\/p>\n
Java SE 26 wird als Release mit regul\u00e4rer Unterst\u00fctzung klassifiziert, Updates werden bis zur n\u00e4chsten Version ver\u00f6ffentlicht. F\u00fcr eine langfristige Unterst\u00fctzung (LTS) sollten Java SE 25, Java SE 21 oder Java SE 17 verwendet werden, deren Updates bis zu den Jahren 2033, 2031 und 2029 ver\u00f6ffentlicht werden (\u00f6ffentlich bis September 2030, 2028 und 2026). Die erweiterte Unterst\u00fctzung der LTS-Zweigstelle Java SE 8 wird bis 2030 dauern, w\u00e4hrend Java SE 11 bis 2032 unterst\u00fctzt wird. <\/p>\n
Unter den \u00c4nderungen in Java SE 26 (1, 2, 3, 4): <\/p>\n
\n
Eine Warnmeldung wird ausgegeben, wenn tiefe Reflexion verwendet wird, um mit dem Schl\u00fcsselwort \u201efinal\u201c gekennzeichnete Felder zu \u00e4ndern. In Zukunft ist geplant, unsichere Sprachm\u00f6glichkeiten standardm\u00e4\u00dfig zu deaktivieren und unter anderem die als final gekennzeichneten Felder vollst\u00e4ndig unver\u00e4nderlich zu machen, indem der Umweg zur \u00c4nderung \u00fcber tiefe Reflexion (API Reflection) entfernt wird.\n
Das API Applet (java.applet.Applet*, javax.swing.JApplet) wurde entfernt, das zum Ausf\u00fchren von Java-Anwendungen im Browser verwendet wurde. Dieses API ist nach der Einstellung des Supports f\u00fcr das Java-Plugin f\u00fcr Browser obsolet geworden und wurde 2021 als veraltet erkl\u00e4rt.\n
Die M\u00f6glichkeit, einen vorab generierten Cache (AOT \u2013 ahead-of-time) mit allen Garbage Collectors, einschlie\u00dflich ZGC (Z Garbage Collector), zu verwenden, wurde implementiert. Diese \u00c4nderung beinhaltet die Unterst\u00fctzung der sequenziellen Ladung von vorab zwischengespeicherten Java-Objekten in den Speicher, wobei ein universelles, unabh\u00e4ngiges Format anstelle einer direkten Zuordnung in speicherabh\u00e4ngige Cache-Darstellungen verwendet wird. Die Verwendung des AOT-Caches verringert die Startzeit und beschleunigt das Warmup der HotSpot-VM.\n
Die Unterst\u00fctzung f\u00fcr das HTTP\/3-Protokoll wurde zur HTTP Client-API hinzugef\u00fcgt, das es Anwendungen und Bibliotheken erm\u00f6glicht, nach minimalen Code\u00e4nderungen auf Server \u00fcber HTTP\/3 zuzugreifen.\n
Die Leistung des G1-Garbage Collectors wurde verbessert, indem die Sperrzeiten zur Synchronisation der Anwendungsthreads mit den Threads des Garbage Collectors verringert wurden.\n
Ein zweiter Vorab-Entwurf der API zum Codieren und Decodieren von Objekten mit kryptografischen Schl\u00fcsseln, Zertifikaten und Sperrlisten f\u00fcr Zertifikate wurde vorgeschlagen, unter Verwendung des PEM-Formats (Privacy-Enhanced Mail).\n
Ein sechster Vorab-Entwurf der API f\u00fcr strukturiertes Parallelismus (Structured Concurrency) wurde zum Testen vorgeschlagen, der die Entwicklung von Multithread-Anwendungen vereinfacht, indem mehrere Aufgaben, die in verschiedenen Threads ausgef\u00fchrt werden, als ein einziger Block behandelt werden.\n
Die zweite vorl\u00e4ufige Version der API Lazy Constants wurde hinzugef\u00fcgt, um mit Objekten zu arbeiten, die unver\u00e4nderliche Daten enthalten und in der JVM als Konstanten verarbeitet werden. Auf solche Objekte werden Leistungsoptimierungen angewendet, die mit Feldern versehen sind, die das Schl\u00fcsselwort \u201efinal\u201c verwenden. Im Gegensatz zu \u201efinal\u201c trennt die neue API die Erstellung konstanter Werte von deren Initialisierung, garantiert, dass der Wert nur einmal initialisiert werden kann, verk\u00fcrzt die Startzeit von Programmen und erm\u00f6glicht die Anwendung von Optimierungen zur Konstantenverkn\u00fcpfung (constant-folding) im Benutzer-Code, die zuvor nur im internen JDK-Code verwendet wurden. class Application { \/\/ Vorher: \/\/ static final UserService USERS = new UserService(); \/\/ Jetzt kann: static final StableValue USERS = StableValue.of(); public static UserService users() { return USERS.orElseSet(UserService::new); } }\n
Im Mustervergleich wurde ein vierter vorl\u00e4ufiger Entwurf f\u00fcr die M\u00f6glichkeit vorgeschlagen, primitive Typen (int, byte, char und andere grundlegende Typen, die keine Objekte sind) in allen Arten von Mustern, im Operator \u201einstanceof\u201c und in \u201eswitch\u201c-Bl\u00f6cken zu verwenden. 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
Es wurde eine elfte Testimplementierung der API Vector vorgeschlagen, die Funktionen f\u00fcr Vektorberechnungen anbietet, die unter Verwendung der Vektorbefehle der x86_64- und AArch64-Prozessoren durchgef\u00fchrt werden und es erm\u00f6glichen, Operationen gleichzeitig auf mehrere Werte anzuwenden (SIMD). Im Gegensatz zu den im JIT-Compiler HotSpot bereitgestellten Automatisierungsfunktionen zur Vektorisierung skalare Operationen, bietet die neue API die M\u00f6glichkeit, die Vektorisierung f\u00fcr die parallele Datenverarbeitung explizit zu steuern. <\/ul>\n
Dar\u00fcber hinaus k\u00fcndigte Oracle das Projekt Detroit an, das im Rahmen von OpenJDK entwickelt werden soll und darauf abzielt, die Portabilit\u00e4t zwischen Java, JavaScript und Python zu verbessern. Im Rahmen des Projekts wird angestrebt, die M\u00f6glichkeit zu bieten, die JVM-Laufzeit mit der JavaScript-Engine V8 und dem CPython-Interpreter einzubetten. Zuvor hatte Oracle bereits die JavaScript-Engine Nashorn entwickelt, die auf der JVM lief, das Projekt jedoch aufgrund der Schwierigkeiten eingestellt, eine separate Implementierung von JavaScript zu entwickeln, w\u00e4hrend das Haupt\u00f6kosystem auf die V8-Engine angewiesen ist. <\/p>\n
Zus\u00e4tzlich kann die Ver\u00f6ffentlichung eines Updates der Plattform zur Erstellung von grafischen Benutzeroberfl\u00e4chen mit JavaFX 26 erw\u00e4hnt werden. In den n\u00e4chsten Stunden wird auch die Ver\u00f6ffentlichung der universellen GraalVM 26 erwartet, die die Ausf\u00fchrung von Anwendungen in JavaScript (Node.js), Python, Ruby, R sowie in allen Sprachen f\u00fcr die JVM (Java, Scala, Clojure, Kotlin) und in Sprachen, f\u00fcr die Bytecode LLVM generiert werden kann (C, C++, Rust), unterst\u00fctzt. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"