{"id":183379,"date":"2026-09-17T16:54:20","date_gmt":"2026-09-17T14:54:20","guid":{"rendered":"https:\/\/prohoster.info\/blog\/news\/vypusk-java-se-27-i-openjdk-27"},"modified":"2026-09-17T16:54:25","modified_gmt":"2026-09-17T14:54:25","slug":"java-se-27-and-openjdk-27-released","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/java-se-27-and-openjdk-27-released","title":{"rendered":"Ver\u00f6ffentlichung von Java SE 27 und OpenJDK 27","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nach sechs Monaten Entwicklungsarbeit hat Oracle die Plattform Java SE 27 (Java Platform, Standard Edition 27) ver\u00f6ffentlicht, deren Referenzimplementierung auf dem offenen OpenJDK-Projekt basiert. Abgesehen von der Entfernung einiger veralteter Funktionen bleibt in Java SE 27 die Abw\u00e4rtskompatibilit\u00e4t zu fr\u00fcheren Java-Plattformversionen erhalten \u2013 die meisten bereits entwickelten Java-Projekte lassen sich ohne \u00c4nderungen auch unter der neuen Version ausf\u00fchren. Installationsfertige Builds von Java SE 27 (JDK, JRE und Server JRE) stehen f\u00fcr Linux (x86_64, AArch64), Windows (x86_64) und macOS (x86_64, AArch64) bereit. Die im Rahmen des OpenJDK-Projekts entwickelte Referenzimplementierung von Java SE 27 ist vollst\u00e4ndig offen und wird unter der GPLv2 mit GNU-ClassPath-Ausnahme bereitgestellt, die eine dynamische Verkn\u00fcpfung mit kommerziellen Produkten erlaubt. <\/p>\n
Java SE 27 geh\u00f6rt zur Kategorie der Releases mit regul\u00e4rer Supportlaufzeit; Updates werden bis zur n\u00e4chsten Ver\u00f6ffentlichung bereitgestellt. Als Versionen mit Langzeitunterst\u00fctzung (LTS) sollten Java SE 25, Java SE 21 oder Java SE 17 eingesetzt werden; f\u00fcr diese erscheinen Updates jeweils bis 2033, 2031 beziehungsweise 2029 (\u00f6ffentlich verf\u00fcgbar jeweils bis September 2030, 2028 und 2026). Der erweiterte Support f\u00fcr den LTS-Zweig Java SE 8 l\u00e4uft bis 2030, f\u00fcr Java SE 11 bis 2032. <\/p>\n
Zu den \u00c4nderungen in Java SE 27 geh\u00f6ren (1, 2, 3, 4): <\/p>\n
\n
Standardm\u00e4\u00dfig wird in allen Umgebungen der Garbage Collector G1 (Garbage-First) verwendet, der zuvor vor allem in Serversystemen zum Einsatz kam. G1 ist f\u00fcr den Einsatz auf Multiprozessorsystemen mit gro\u00dfem Arbeitsspeicher optimiert und auf ein ausgewogenes Verh\u00e4ltnis zwischen vorhersehbaren Latenzen und hohem Durchsatz ausgelegt. Im Betrieb unterteilt G1 den Speicher in viele kleine Regionen und bereinigt vorrangig jene Bereiche, in denen sich mehr ungenutzte Objekte und weniger aktiv verwendete Daten befinden.\n
In der HotSpot JVM sind kompakte Objekt-Header standardm\u00e4\u00dfig aktiviert. Die Header-Gr\u00f6\u00dfe auf 64-Bit-Systemen wurde von 96 auf 64 Bit reduziert, was den Speicherverbrauch senkt und die Wahrscheinlichkeit erh\u00f6ht, dass Daten im Prozessor-Cache landen. In SPECjbb2015-Tests sank der Speicherverbrauch um 22 %, die CPU-Last ging um 8 % zur\u00fcck und die Zahl der Garbage-Collection-Vorg\u00e4nge verringerte sich um 15 %. Beim Testen des JSON-Parsers verk\u00fcrzte sich die Ausf\u00fchrungszeit der Tests um 10 %.\n
Zur TLS-1.3-Implementierung wurde Unterst\u00fctzung f\u00fcr hybride Schl\u00fcsselaushandlungsschemata hinzugef\u00fcgt, die den gegen Brute-Force-Angriffe auf Quantencomputern resistenten ML-KEM-Algorithmus (CRYSTALS-Kyber) mit klassischen ECDHE-Algorithmen auf Basis elliptischer Kurven kombinieren: X25519MLKEM768 (ECDHE mit der Kurve X25519 + ML-KEM-768), SecP256r1MLKEM76 (ECDHE mit der Kurve secp256r1 + ML-KEM-768) und SecP384r1MLKEM1024 (ECDHE mit der Kurve secp384r1 + ML-KEM-1024). Im API javax.net.SSL<\/a> Diese Schemata sind standardm\u00e4\u00dfig aktiviert und erfordern f\u00fcr den Einsatz keine \u00c4nderungen an Anwendungen.\n