{"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\/novosti-interneta\/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 der Unterst\u00fctzung von 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, die als Referenzimplementierung das Open-Source-Projekt OpenJDK nutzt. Abgesehen von der Entfernung einiger veralteter Funktionen in Java SE 26 bleibt die Abw\u00e4rtskompatibilit\u00e4t zu vorherigen Versionen der Java-Plattform erhalten \u2013 die meisten zuvor geschriebenen Java-Projekte funktionieren unver\u00e4ndert unter der neuen Version. Installationsbereite 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 Projekts OpenJDK entwickelte Referenzimplementierung von Java SE 26 ist vollst\u00e4ndig unter der GPLv2-Lizenz mit Ausnahmen von GNU ClassPath ver\u00f6ffentlicht, die das dynamische Binden an kommerzielle Produkte erlauben. <\/p>\n
Java SE 26 geh\u00f6rt zur Kategorie der Releases mit regul\u00e4rer Supportdauer, f\u00fcr die Updates bis zur n\u00e4chsten Ver\u00f6ffentlichung bereitgestellt werden. Bei den Long-Term-Support (LTS)-Versionen sollten Java SE 25, Java SE 21 oder Java SE 17 verwendet werden, f\u00fcr die Updates bis 2033, 2031 und 2029 ver\u00f6ffentlicht werden (\u00f6ffentlich bis September 2030, 2028 und 2026). Die erweiterte Unterst\u00fctzung der LTS-Version Java SE 8 wird bis 2030 andauern, w\u00e4hrend Java SE 11 bis 2032 unterst\u00fctzt wird. <\/p>\n
Zu den \u00c4nderungen in Java SE 26 (1, 2, 3, 4): <\/p>\n
\n
Eine Warnmeldung wurde implementiert, wenn tiefe Reflexion verwendet wird, um mit dem Schl\u00fcsselwort \"final\" gekennzeichnete Felder zu \u00e4ndern. Zuk\u00fcnftig ist geplant, standardm\u00e4\u00dfig unsichere Sprachfunktionen zu deaktivieren und unter anderem Felder, die als final markiert sind, vollst\u00e4ndig unver\u00e4nderlich zu machen, indem der Umweg zur \u00c4nderung \u00fcber tiefe Reflexion (API Reflection) entfernt wird.\n
Die API Applet (java.applet.Applet*, javax.swing.JApplet), die zur Ausf\u00fchrung von Java-Anwendungen im Browser verwendet wurde, wurde entfernt. Diese API hat nach dem Ende des Supports f\u00fcr das Java-Plugin f\u00fcr Browser ihre Relevanz verloren und wurde 2021 als veraltet erkl\u00e4rt.\n
Die M\u00f6glichkeit, vorab den Cache (AOT - Ahead-of-Time) mit beliebigen Garbage Collectors, einschlie\u00dflich ZGC (Z Garbage Collector), zu verwenden, wurde implementiert. Diese \u00c4nderung unterst\u00fctzt das sequenzielle Laden von zwischengespeicherten Java-Objekten in den Speicher, indem ein universelles und unabh\u00e4ngig von den Garbage Collectors verwendetes Format anstelle einer direkten Abbildung auf speziellem Cache-Speicher verwendet wird. Die Nutzung des AOT-Caches reduziert die Startzeit und beschleunigt das Warmup der HotSpot-VM.\n
Im HTTP Client API wurde die Unterst\u00fctzung des HTTP\/3-Protokolls hinzugef\u00fcgt, die es Anwendungen und Bibliotheken erm\u00f6glicht, Server \u00fcber HTTP\/3 mit minimalen \u00c4nderungen im Code anzusprechen.\n
Die Leistung des Garbage Collectors G1 wurde verbessert, indem die Sperrzeiten zur Synchronisation von Anwendungs-Threads mit Threads des Garbage Collectors reduziert wurden.\n
Eine zweite Vorabversion der API zum Kodieren und Dekodieren von Objekten mit kryptografischen Schl\u00fcsseln, Zertifikaten und Listen widerrufener Zertifikate unter Verwendung des PEM-Formats (Privacy-Enhanced Mail) wurde vorgeschlagen.\n
Die sechste Vorabversion der API f\u00fcr strukturierten Parallelismus (Structured Concurrency) wurde f\u00fcr Testzwecke angeboten. Diese API vereinfacht die Entwicklung von Multithread-Anwendungen, indem mehrere in verschiedenen Threads ausgef\u00fchrte Aufgaben als ein einzelner Block behandelt werden.\n
Eine zweite Vorabversion 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 denen von Feldern mit dem Schl\u00fcsselwort \"final\" \u00e4hneln. Anders als bei \"final\" trennt die neue API die Erstellung von konstanten Werten und deren Initialisierung, garantiert, dass ein Wert nur einmal initialisiert werden kann, reduziert die Startzeit von Programmen und erm\u00f6glicht es, in Benutzercode Optimierungen wie Constant-Folding anzuwenden, die zuvor nur im internen Code des JDK verwendet wurden. class Application { \/\/ War: \/\/ static final UserService USERS = new UserService(); \/\/ Jetzt kann man: static final StableValue USERS = StableValue.of(); public static UserService users() { return USERS.orElseSet(UserService::new); } }\n
Im Musterabgleich wurde eine vierte Vorabversion der M\u00f6glichkeit vorgestellt, primitive Typen (int, byte, char und andere grundlegende Typen, die keine Objekte sind) in allen Formen von Mustern, im \"instanceof\"-Operator und in \"switch\"-Bl\u00f6cken zu verwenden. switch (x.getStatus()) { case 0 -> \"okay\"; case 1 -> \"warning\"; case 2 -> \"error\"; case int i -> \"unknown status: \" + i; } if (i instanceof byte b) { ... b ... }\n
Eine elfte Testimplementierung der API Vector wurde vorgeschlagen, die Funktionen f\u00fcr vektorielle Berechnungen bereitstellt, die mit Vektor-Instruktionen der Prozessoren x86_64 und AArch64 durchgef\u00fchrt werden und die es erm\u00f6glichen, Operationen gleichzeitig auf mehrere Werte anzuwenden (SIMD). Im Gegensatz zu den im JIT-Compiler HotSpot verf\u00fcgbaren M\u00f6glichkeiten zur automatischen Vektorisierung skalaren Operationen, bietet die neue API die M\u00f6glichkeit, die Vektorisierung f\u00fcr die parallele Datenverarbeitung explizit zu steuern. <\/ul>\n
Dar\u00fcber hinaus hat Oracle das Projekt Detroit angek\u00fcndigt, das Teil von OpenJDK wird und darauf abzielt, die Portabilit\u00e4t zwischen Java, JavaScript und Python zu verbessern. Im Rahmen des Projekts wird angestrebt, die Integration in den JVM-Laufzeitprozess mit der JavaScript-Engine V8 und dem CPython-Interpreter zu erm\u00f6glichen. Zuvor hatte Oracle bereits die JavaScript-Engine Nashorn entwickelt, die auf der JVM lief, aber das Projekt eingestellt, da es schwierig war, eine separate Implementierung von JavaScript zu entwickeln, w\u00e4hrend das Haupt\u00f6kosystem auf der V8-Engine basiert. <\/p>\n
Zus\u00e4tzlich ist es erw\u00e4hnenswert, dass ein Update der Plattform f\u00fcr die Entwicklung von grafischen Benutzeroberfl\u00e4chen mit JavaFX 26 ver\u00f6ffentlicht wurde. In den n\u00e4chsten Stunden wird auch die Ver\u00f6ffentlichung der universellen virtuellen Maschine GraalVM 26 erwartet, die die Ausf\u00fchrung von Anwendungen in JavaScript (Node.js), Python, Ruby, R, allen Sprachen f\u00fcr die JVM (Java, Scala, Clojure, Kotlin) und in Sprachen, f\u00fcr die Bitcode 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":"