Java 27: Sicherheit, Laufzeit und reifende APIs

Java 27 macht nicht mit einem einzelnen großen Sprachfeature auf sich aufmerksam, aber an mehreren Stellen gibt es Änderungen, die für den praktischen Betrieb von Java-Anwendungen relevant sind: Die HotSpot VM spart Speicher, G1 wird als Default vereinheitlicht, TLS bereitet sich auf Post-Quantum-Kryptografie vor und Java Flight Recorder geht vorsichtiger mit sensiblen Daten um. Gleichzeitig reifen mehrere Preview-APIs.

Insgesamt bringt Java 27 neun JDK Enhancement Proposals (JEPs):

• JEP 523: Make G1 the Default Garbage Collector in All Environments
• JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3
• JEP 531: Lazy Constants (Third Preview)
• JEP 532: Primitive Types in Patterns, instanceof, and switch (Fifth Preview)
• JEP 533: Structured Concurrency (Seventh Preview)
• JEP 534: Compact Object Headers by Default
• JEP 536: JFR In-Process Data Redaction
• JEP 537: Vector API (Twelfth Incubator)
• JEP 538: PEM Encodings of Cryptographic Objects (Third Preview)

Im Fokus der Online-Konferenz betterCode() Java am 13. Oktober stehen die Neuerungen der jüngsten Java-Releases und wie sie dabei helfen können, Java-Anwendungen effizienter zu gestalten.

Dabei geht es zum einen um Features wie Pattern Matching und Structured Concurrency. Zum anderen wirft die Konferenz einen Blick unter die Haube und zeigt, was sich seit Java 17 beim Garbage Collector, der Time-to-Peak-Performance und der JVM-Start-up-Zeit getan hat.

Vier JEPs bringen neue oder erstmals standardmäßig aktivierte Funktionalität und fünf sind Wiedervorlagen bereits bekannter Preview- oder Incubator-Features. Interessanter als die konkreten Inhalte der einzelnen JEPS ist die Frage, welche Themen sich hinter den Änderungen verbergen. Dabei lassen sich drei größere Linien erkennen: mehr Sicherheit, bessere Laufzeiteffizienz und die weitere Konsolidierung von APIs, die in den vergangenen Releases begonnen wurden.

Sicherheit wird zum Laufzeit-Feature

Ein auffälliger Schwerpunkt von Java 27 liegt im Security-Bereich. Dabei geht es nicht nur um neue APIs, sondern auch um Funktionen, die bestehende Anwendungen allein durch ein JDK-Update sicherer machen können.

Post-Quantum-Kryptografie erreicht TLS 1.3

Mit JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3 führt Java hybride Post-Quantum-Schlüsselaustauschverfahren für TLS 1.3 ein. Was zunächst nach Zukunftsmusik klingt, adressiert ein Problem, das bereits heute relevant sein kann. Aktuelle TLS-Verbindungen verwenden für den Schlüsselaustausch unter anderem elliptische Kurven. Ein hinreichend leistungsfähiger Quantencomputer könnte die dafür zugrunde liegenden mathematischen Probleme mit dem Shors-Algorithmus wesentlich effizienter lösen als klassische Rechner.

Quantencomputer stehen heute noch nicht zur Verfügung, aber Angreifer können bereits jetzt verschlüsselten Netzwerkverkehr aufzeichnen und darauf hoffen, ihn in einigen Jahren entschlüsseln zu können. Dieses Szenario wird häufig als „Harvest now, decrypt later“ bezeichnet.

Java 27 unterstützt deshalb drei hybride Named Groups:

X25519MLKEM768 SecP256r1MLKEM768 SecP384r1MLKEM1024

Sie kombinieren jeweils einen klassischen ECDHE-Schlüsselaustausch mit dem quantenresistenten ML-KEM. Die Idee hinter dem hybriden Ansatz ist pragmatisch: Post-Quantum-Verfahren sind noch jung, während klassische Verfahren seit Jahrzehnten untersucht werden. Durch die Kombination hängt die Sicherheit nicht allein an einer neuen kryptografischen Annahme.

Für Anwendungen ist die Änderung weitgehend transparent. X25519MLKEM768 gehört in Java 27 zu den bevorzugten TLS-1.3-Gruppen. Unterstützt die Gegenstelle das Verfahren ebenfalls, können die Systeme es beim normalen TLS-Handshake aushandeln. Bestehenden Code mit JSSE, HTTPS oder HttpClient muss man dafür nicht ändern. Die Release Notes von Java 27 weisen ausdrücklich darauf hin, dass Anwendungen mit javax.net.ssl von den neuen Algorithmen standardmäßig profitieren können.

Bei Bedarf lässt sich die Auswahl weiterhin über jdk.tls.namedGroups oder über SSLParameters.setNamedGroups() beeinflussen.

Java Flight Recorder schützt sensible Daten früher

Security betrifft nicht nur Kryptografie: Auch Diagnosedaten können ein Risiko darstellen. Java Flight Recorder sammelt unter anderem Informationen über Kommandozeilenargumente, System Properties und Umgebungsvariablen. Dort finden sich in realen Systemen häufig Passwörter, Token oder andere Zugangsdaten.

JEP 536 führt deshalb JFR In-Process Data Redaction* ein. Sensible Werte werden nicht erst nachträglich aus einer .jfr-Datei entfernt, sondern bereits beim Erzeugen der Events innerhalb der JVM ersetzt. Ein Eintrag wie

javax.net.ssl.keyStorePassword = secret123

erscheint dadurch nur noch als

javax.net.ssl.keyStorePassword = [REDACTED]

im Recording.

Die Erkennung basiert auf konfigurierbaren Regeln für Namen von System Properties, Umgebungsvariablen und Kommandozeilenargumenten. Typische Begriffe wie password, secret, token, credential, api-key oder client-secret werden standardmäßig berücksichtigt. Eigene Regeln kann man über das Flag -XX:FlightRecorderOptions ergänzen.

Der entscheidende Punkt ist nicht die konkrete Schreibweise der Filter, sondern der Ort der Bereinigung: Das Secret landet im Normalfall gar nicht erst in der Recording-Datei. Gerade weil Entwicklungstreams JFR-Dateien häufig an andere Teams, Support-Abteilungen oder Hersteller weitergeben werden, ist das ein sinnvolles und sicheres Standardvorgehen.

PEM bekommt eine richtige Java-API

Der dritte Security-Baustein ist weniger unsichtbar, dafür im Anwendungscode direkt nutzbar. Für Zertifikate und Schlüssel kommt häufig das PEM-Format zum Einsatz:

-----BEGIN PUBLIC KEY-----

-----END PUBLIC KEY-----

Obwohl dieses Format praktisch überall im TLS-, Cloud- und Kubernetes-Umfeld auftaucht, musste Java-Code bisher häufig selbst Header und Footer behandeln, Base64 dekodieren und anschließend passende Security-APIs zusammensetzen.

Die mit JEP 538 zum dritten Mal vorgelegte PEM-API abstrahiert diese Aufgaben. PEMEncoder und PEMDecoder können kryptografische Objekte direkt in das PEM-Format schreiben beziehungsweise daraus lesen.

Java 27 verallgemeinert die API weiter und ersetzt das bisherige DEREncodable durch BinaryEncodable. Das zeigt klarer, dass die API nicht unnötig auf Distinguished Encoding Rules (DER) als einzige mögliche binäre Repräsentation festgelegt sein soll. Unter anderem verwenden X509Certificate, KeyPair, PKCS8EncodedKeySpec und EncryptedPrivateKeyInfo die allgemeinere Abstraktion.

Auch der Decoder bringt in Java 27 ein paar Änderungen mit: withFactory(Provider) heißt nun präziser withFactoriesOf(Provider), und mit CryptoException kommt ein gemeinsamer Exception-Typ für entsprechende kryptografische Operationen hinzu. Die Änderungen lassen sich gut im Java-Almanac nachvollziehen.

Für Anwendungen bedeutet die PEM-API vor allem weniger eigener Parsing-Code und weniger Abhängigkeit von Drittbibliotheken für grundlegende Anwendungsfälle.

Weniger Overhead in der HotSpot VM

Ein zweiter Schwerpunkt von Java 27 liegt unterhalb der Java-Sprache. Zwei JEPs verändern Defaults der Laufzeitumgebung und können dadurch bestehende Anwendungen beeinflussen, ohne dass Entwicklerinnen und Entwickler eine einzige Quellcodezeile ändern müssen.

Compact Object Headers werden Standard

Jedes Java-Objekt besitzt neben seinen eigentlichen Daten Verwaltungsinformationen. Dazu gehören unter anderem Informationen über den Typ des Objekts, Synchronisation und der Identity Hash Code. Auf einer typischen 64-Bit-HotSpot-VM mit komprimierten Class Pointern bestand der Objekt-Header bisher aus einem Mark Word mit 64 Bit und einem Class Word mit 32 Bit. Das ergibt 96 Bit beziehungsweise zwölf Byte zusätzlich zu den eigentlichen Feldern des Objekts.

Project Lilliput arbeitet seit mehreren Jahren daran, diesen Overhead zu reduzieren. Compact Object Headers integrieren den Class Pointer in das Mark Word und verkleinern den Header dadurch auf 64 Bit beziehungsweise acht Byte. Java 24 hat Compact Object Headers zunächst experimentell angeboten, Java 25 machte sie zu einem regulären, aber weiterhin optionalen Feature. JEP 534 aktiviert sie in Java 27 standardmäßig.

Wer das bisherige Layout benötigt, kann vorerst zurückschalten:

java -XX:-UseCompactObjectHeaders ...

Vier Byte Unterschied wirken zunächst unspektakulär. Bei sehr vielen kleinen Objekten kann der Effekt aber erheblich sein. Die JEP-Dokumentation zeigt in ausgewählten Benchmarks sowohl geringeren Heap-Bedarf als auch weniger Arbeit des Garbage Collector (GC) und Verbesserungen bei CPU-Zeit und Datenlokalität. Solche Zahlen sind allerdings keine allgemeine Performance-Garantie: Wie stark eine reale Anwendung profitiert, hängt von dem Objektmodell und dem Workload ab. Für normalen Java-Code bleibt die Änderung transparent. Etwas genauer hinschauen sollten dagegen diejenigen, die JVM-nahe Tools, Agents und Bibliotheken entwickeln, die Annahmen über das konkrete Speicherlayout von Objekten treffen.

G1 wird wirklich überall Default

Auch JEP 523 verändert einen lange bestehenden Default. Seit Java 9 gilt G1 als Standard-Garbage-Collector der HotSpot VM. Auf sehr kleinen Systemen gab es bisher jedoch eine Ausnahme: Unter bestimmten Bedingungen wählte HotSpot automatisch den Serial GC. Diese Sonderbehandlung entfällt in Java 27. Wenn kein Garbage Collector explizit konfiguriert ist, startet die JVM unabhängig von der erkannten Umgebung mit dem G1.

Der Serial GC bleibt weiterhin verfügbar:

java -XX:+UseSerialGC ...

Für typische Server-Anwendungen ändert sich dadurch nichts, weil sie ohnehin bereits vor Java 27 mit G1 liefen. Interessant ist die Neuerung vor allem für kleine Container. Bisher konnte eine Änderung der CPU- oder Memory-Limits indirekt dazu führen, dass dieselbe Anwendung mit einem anderen Garbage Collector startete. Mit Java 27 ist dieses Verhalten vorhersehbarer. Die Änderung passt außerdem gut zu den Optimierungen aus Java 26, das Verbesserungen für G1 mitbrachte, insbesondere bei kleinen Heaps und vielen Threads.