Hallo zusammen,
seit dem letzten Artikel über Java 24 und Java 25 ist ein halbes Jahr vergangen – und Java tickt weiter im gewohnten Sechs-Monats-Takt. Am 17. März 2026 ist Java 26 erschienen, das erste Release nach dem LTS-Meilenstein Java 25. Kein Long-Term-Support diesmal, dafür wieder ein Paket aus fertigen Features und Previews, die zeigen, wohin die Plattform sich entwickelt.
Java 26 bringt zehn JEPs mit: fünf davon sind final, vier stecken in der nächsten Preview-Runde, einer im Incubator. Diesmal geht es weniger um spektakuläre neue Syntax, sondern um Fundament-Arbeit: HTTP/3, ein schnellerer JVM-Start dank Ahead-of-Time Object Caching, mehr Durchsatz beim G1 Garbage Collector – und eine Änderung, die stiller daherkommt, aber Konsequenzen für bestehenden Code haben kann.
Schauen wir uns an, was wirklich ankommt.
Die finalisierten Features
HTTP/3 für den HTTP Client (JEP 517)
Der HTTP Client aus dem java.net.http Paket unterstützt jetzt auch HTTP/3, das auf dem QUIC-Protokoll aufbaut. QUIC bringt Flow-Control auf Stream-Ebene, geringere Latenz beim Verbindungsaufbau und die Fähigkeit, Netzwerkpfade zu wechseln, ohne die Verbindung zu verlieren – praktisch, wenn dein Client zwischen WLAN und Mobilfunk springt.
Der Umstieg ist bewusst kein Autopilot. Du forderst HTTP/3 explizit an, sonst bleibt HTTP/2 der Standard:
HttpRequest request = HttpRequest.newBuilder()
.uri(URI.create("https://julianpaul.dev/"))
.version(HttpClient.Version.HTTP_3)
.build();
Unterstützt der Server kein HTTP/3, fällt der Client transparent auf HTTP/2 zurück. Für dich ändert sich im Anwendungscode kaum etwas – die Migration ist eine Ein-Zeilen-Änderung, kein Rewrite.
Schnellerer Start dank AOT Object Caching für jeden GC (JEP 516)
Project Leyden liefert mit Java 26 einen weiteren Baustein für schnellere Startzeiten. Der AOT-Cache (Ahead-of-Time) konnte bisher nicht mit jedem Garbage Collector zusammenarbeiten – vor allem ZGC, der Collector für niedrige Latenzen, blieb außen vor, weil die gecachten Objekte direkt im GC-spezifischen Format abgelegt wurden.
JEP 516 löst das, indem Objekte in einem GC-neutralen Format sequenziell geladen werden, statt sie 1:1 in ein bestimmtes GC-Layout zu mappen. Das Ergebnis: Der AOT-Cache funktioniert jetzt mit jedem Garbage Collector, ohne dass du bei der Startperformance Abstriche machst. Für Cloud-native Anwendungen mit kurzer Lebensdauer – klassische Microservices, Lambda-artige Workloads – ist das ein handfester Gewinn.
G1 GC: Mehr Durchsatz durch weniger Synchronisation (JEP 522)
Der G1 Garbage Collector balanciert seit jeher zwischen Latenz und Durchsatz. Der Preis dafür: Application-Threads müssen sich mit GC-Threads koordinieren, was Synchronisationsaufwand erzeugt. JEP 522 reduziert diesen Aufwand und verkleinert den Code, den die JVM für Write-Barrier-Checks einfügt – ohne die grundlegende Architektur von G1 anzufassen.
Das ist kein Feature, das du im Code siehst. Es ist einer der Fälle, in denen ein Minor-Release einfach schneller wird, ohne dass du etwas dafür tun musst.
Aufräumarbeiten: Die Applet API ist Geschichte (JEP 504)
Seit Java 17 als “deprecated for removal” markiert, ist die Applet API mit Java 26 endgültig entfernt. Kein aktueller Browser unterstützt Applets mehr, und kein aktuelles JDK hat sie in den letzten Jahren sinnvoll ausführen können. Wenn dein Code irgendwo noch java.applet.* importiert – das ist der Zeitpunkt, es endgültig zu entsorgen.
Die stille Revolution: Warnings für finale Felder (JEP 500)
Das unscheinbarste JEP in diesem Release ist gleichzeitig das mit dem größten Sprengpotenzial für bestehende Codebasen. Bisher konnte Reflection ein final-Feld problemlos überschreiben – final war also nie wirklich final, sondern eher eine Empfehlung, die sich mit setAccessible(true) aushebeln ließ. Viele Frameworks (Serialisierung, Dependency Injection, Test-Mocking) machen genau davon Gebrauch.
Java 26 beginnt, das zu beenden. Mutiert dein Code per Reflection ein finales Feld, bekommst du ab sofort eine Warnung:
WARNING: Final field value in class dev.julianpaul.example.Box
has been mutated reflectively
WARNING: Mutating final fields will be blocked in a future release
Noch läuft dein Code weiter – JEP 500 ist reine Vorbereitung, kein Bruch. Du steuerst das Verhalten über ein VM-Flag:
# Standard in Java 26: nur warnen
--illegal-final-field-mutation=warn
# Zukünftiges Verhalten schon jetzt testen: blockieren
--illegal-final-field-mutation=deny
Pro-Tipp: Wenn du Frameworks wie Jackson, Gson, Mockito oder ältere DI-Container einsetzt, lohnt sich ein Testlauf mit
--illegal-final-field-mutation=denyin einer CI-Pipeline. So siehst du frühzeitig, welche Abhängigkeiten in einer zukünftigen Java-Version brechen könnten – lange bevor es in Produktion ein Problem wird.
Das ist der erste sichtbare Schritt Richtung “final heißt final”. Für dich heißt das: Wenn du selbst finale Felder als Erweiterungspunkt nutzt (bewusst oder aus Gewohnheit), ist jetzt der richtige Zeitpunkt, das zu überdenken.
Was als Preview schon durchschimmert
Neben den finalen Features zeigt Java 26, woran im Hintergrund gearbeitet wird. Drei Previews sind besonders interessant, weil sie zeigen, wo die nächsten LTS-Versionen hinsteuern.
Lazy Constants (JEP 526, 2. Preview)
Bisher war die Wahl bei Feldern binär: entweder final und beim Erzeugen des Objekts initialisiert, oder veränderlich und ohne die Performance-Garantien von final. Lazy Constants schließen die Lücke – ein Wert wird erst bei seiner ersten Nutzung berechnet, gilt der JVM danach aber als echte Konstante:
private final LazyConstant<Settings> settings =
LazyConstant.of(this::loadSettingsFromDatabase);
public Locale getLocale() {
return settings.get().getLocale();
}
Es gibt auch Varianten für Collections, die jedes Element erst bei Bedarf berechnen:
private final List<Double> squareRoots = List.ofLazy(100, Math::sqrt);
Das ist vor allem für teure Initialisierungen interessant – Konfigurationsdaten, Ressourcen, die erst beim ersten Request gebraucht werden – ohne dass du dafür ein eigenes Double-Checked-Locking-Konstrukt schreiben musst.
Structured Concurrency (JEP 525, 6. Preview)
Structured Concurrency begleitet uns schon seit mehreren Java-Versionen als Preview und reift weiter. Die Idee bleibt: Zusammengehörige Tasks auf verschiedenen Threads werden als eine Einheit behandelt, mit sauberer Fehlerbehandlung und Cancellation statt manuell verwalteter Thread-Leichen. Die 6. Preview bringt vor allem Verfeinerungen an der API – ein Zeichen, dass eine Finalisierung näher rückt.
Primitive Types in Patterns (JEP 530, 4. Preview)
Pattern Matching kennt bisher primitive Typen nur eingeschränkt. JEP 530 erlaubt jetzt Pattern Matching direkt auf byte, short, int, double & Co. – auch in switch:
double value = ...;
switch (value) {
case byte b -> IO.println(value + " passt in byte: " + b);
case short s -> IO.println(value + " passt in short: " + s);
case int i -> IO.println(value + " passt in int: " + i);
case double d -> IO.println(value + " bleibt double: " + d);
}
Das macht Pattern Matching konsistent für alle Typen – egal ob Referenz- oder primitiver Typ – und ist ein weiterer Baustein auf dem Weg zu wirklich einheitlichem, ausdrucksstarkem Pattern Matching in Java.
Pro-Tipps / Warnungen
Nicht produktiv einsetzen ohne Plan: Java 26 ist non-LTS. Für Produktionssysteme bleibt Java 25 (LTS) bis mindestens 2027 die solidere Wahl. Java 26 lohnt sich, wenn du frühzeitig sehen willst, wohin die Plattform steuert, oder gezielt Features wie HTTP/3 oder AOT Object Caching mit ZGC ausprobieren willst.
JEP 500 jetzt schon testen: Warte nicht, bis
--illegal-final-field-mutation=denyzum Standard wird. Wenn du Reflection-lastige Libraries im Stack hast, teste jetzt gegen Java 26 mit aktiviertem Deny-Modus – lieber eine Warnung heute als ein Breaking Change in zwei Jahren.
Fazit: Kontinuität statt großer Sprünge
Java 26 ist kein Release der lauten Schlagzeilen – dafür eines der soliden Fundamentarbeit. HTTP/3, ein GC-unabhängiger AOT-Cache und ein durchsatzstärkerer G1 sind handfeste Verbesserungen, die im Hintergrund wirken. Die eigentlich relevante Entwicklung ist JEP 500: Der erste sichtbare Schritt, final wirklich final zu machen, betrifft potenziell jede Codebasis, die auf Reflection-basierte Frameworks setzt.
Die Previews – Lazy Constants, Structured Concurrency, Primitive Types in Patterns – zeigen, dass die großen Baustellen aus den letzten Releases konsequent weitergeführt werden. Mit Java 27 im September 2026 geht der Sechs-Monats-Rhythmus nahtlos weiter. Bis dahin lohnt sich ein Blick auf Java 26, gerade wenn du HTTP/3 oder ZGC im Einsatz hast.