Die Veröffentlichung für das OpenJDK 25 ist für den 16. September 2025 vorgesehen. Diesmal sind 18 JEPs (JDK Enhancement Proposals) eingeplant. Das ist zwar etwas weniger als noch bei Java 24, aber dafür werden dieses Mal einige Features nach vorangehenden Previews finalisiert. Außerdem bieten die meisten Distributoren für Java 25 wieder einen verlängerten Support (LTS) an. Viele Java-Projekte wechseln in den nächsten Monaten vom letzten LTS Release 21 zu 25.

Wir werfen hier einen ersten Blick auf die aus Developer-Sicht interessantesten Punkte. Weitere Details lassen sich über die jeweiligen JEPs nachvollziehen. In einem zweiten Post betrachten wir dann die weiteren Änderungen, die mehr unter der Haube versteckt oder nicht so relevant für die Java-Entwicklerinnen und -Entwickler sind. Die meisten in diesem Beitrag beschriebenen JEPs sind übrigens Wiedervorlagen, die bereits in früheren Java-Versionen als Inkubator oder Preview veröffentlicht wurden. Ganz neu sind die Stable Values, die eine größere Flexibilität bei der Initialisierung von final-Feldern bieten.

JEP 502: Stable Values

Stable Values sind Objekte, die genau einmal zum Einsatz kommen und danach unveränderlich sind. Die JVM (Java Virtual Machine) behandelt ihren Inhalt wie eine echte Konstante und kann dieselben Optimierungen (zum Beispiel Constant Folding) anwenden, wie bei final‑Feldern – nur, dass die Initialisierung beliebig spät erfolgen darf. Damit bekommt Java eine „Deferred Immutability“, die Start‑ und Aufwärmzeiten verkürzt, ohne Sicherheitsrisiken mit Thread einzugehen. Die Ziele sind:

• Schnelleres Start‑Up: Keine monolithische Initialisierung aller Komponenten mehr.
• Entkopplung von Erzeugung & Initialisierung eines unveränderlichen Werts – ohne Performance‑Kosten.
• Garantierte At‑Most‑Once‑Initialisierung auch in hoch parallelen Szenarien.
• Konstanten‑Optimierungen für Anwendungscode zugänglich machen, nicht nur für JDK‑internen Code.

Stable Values sind eine reine Library‑API. Es wird kein neues Schlüsselwort geben. Außerdem gibt es keine Änderung an der Semantik von final, bestehender Code bleibt unberührt. Bisher müssen final‑Felder eager (sofort) initialisiert werden – die Initialisierung eines Loggers oder eine Datenbank‑Connection bremst so den Programmstart aus. Workarounds wie Lazy Holder, Double‑Checked Locking oder ConcurrentHashMap.computeIfAbsent sind entweder eingeschränkt, fehleranfällig oder verhindern JIT‑Optimierungen (Just in Time). Stable Values schließen die Lücke zwischen strenger Immutability und flexibler Lazy‑Initialisierung.

Der Lambda-Ausdruck in orElseSet wird garantiert genau einmal ausgeführt, selbst wenn mehrere Virtual Threads gleichzeitig logger() aufrufen. Danach kann der JIT (Just in Time Compiler der Hotspot VM) alle Zugriffe optimieren, wie durch Constant Folding.

class OrderController {
    private final StableValue logger = StableValue.of();

    private Logger logger() {
        return logger.orElseSet(() -> Logger.create(OrderController.class));
    }
}

Stable Values sind besonders für parallele Programmierung interessant. Im Umfeld von Virtual Threads arbeitet das Entwicklerteam schon seit Längerem an weiteren Bausteinen. Während Structured Concurrency bereits zum sechsten Mal als Preview dabei ist, gelten die Scoped Values nach vier Previews jetzt als final.

JEP 506 – Scoped Values (Final in JDK 25)

Scoped Values sind eine Alternative zu ThreadLocal-Variablen, die Threads unterschiedliche Zugriffe auf einen globalen Zustand ermöglichen. ThreadLocal lässt sich beliebig ändern, hat eine unbegrenzte Lebensdauer (Leak-Gefahr, vor allem in Pools) und ist teurer durch Vererbung an Kind-Threads. Scoped Values begrenzen die Lebensdauer klar, sind read-only und lassen sich über viele Threads hinweg platz- und zeitsparend nutzen. Gegenüber den Previews wird die API finalisiert. Einzige Änderung: ScopedValue.orElse akzeptiert kein null mehr. Ein Web-Framework bindet beispielsweise einmal pro Request den FrameworkContext (zum Beispiel Spring ApplicationContext oder ein AuthenticationContext). Die Handler und interne Framework-Aufrufe (etwa DB-Zugriff) können auf diesen FrameworkContext zugreifen, ohne dass er immer als zusätzlicher Parameter durchgereicht werden muss. Und auch in Kind-(Virtual) Threads ist er automatisch verfügbar.

JEP 505 – Structured Concurrency (Preview)

Mit dem StructuredTaskScope erhält eine API Einzug, die zusammengehörige Nebenläufigkeit als eine Einheit behandelt: Subtasks werden im Block geforkt und über ein join() wieder zusammengeführt. Fehler sorgen gegebenenfalls für einen direkten Abbruch anderer Subtasks. Beim Debugging lässt sich in den Thread-Dumps die Task-Hierarchie leicht nachvollziehen. Damit erlaubt Structured Concurrency die Implementierung auf eine besonders les- und wartbare Art und Weise. Alternativ konnten Entwicklerinnen und Entwickler für diesen Zweck bisher die Parallel Streams, den ExecutorService oder reaktive Programmierung einsetzen. Alles sehr mächtige Ansätze, die aber gerade einfache Umsetzungen unnötig kompliziert und fehleranfällig machen.

Neu gegenüber der letzten Preview: Scopes lassen sich über statische Fabrikmethoden öffnen (open() für den Standardfall, d. h. entweder sind alle erfolgreich oder bei einem Fehler bricht alles ab). Alternative Abschluss-Policies und Rückgabewerte werden über Joiner-basierte open(...)-Varianten gesteuert. Ziele sind unter anderem das Vermeiden von Thread-Leaks und Cancellation-Delays sowie bessere Observability. Nicht beabsichtigt ist der Ersatz von ExecutorService/Future, neue Channel-Primitiven oder eine neue Cancel-Mechanik. Gerade bei I/O-Fan-out mit Virtual Threads wird die Koordination einfacher, robuster und nachvollziehbarer.

// --enable-preview beim Kompilieren und Starten 
record Response(String user, int order) {}

Response handle() throws InterruptedException {
  try (var scope = StructuredTaskScope.

Trotz seiner 30 Jahre zieht Java auch weiter viele Programmierneulinge an. Die JEPs 511 (Module Import Declarations) und 512 (Compact Source Files and Instance Main Methods) helfen aber nicht nur Anfängern, sie machen auch erfahrenen Developern das Leben einfacher. Beide JEPs erreichen nun nach mehreren vorangegangenen Previews den finalen Status.

JEP 511 – Module Import Declarations (Final in JDK 25)

Dieses JEP ergänzt die Sprache um import module , sodass alle exportierten Pakete eines Moduls mit einer Deklaration verfügbar sind. Das reduziert Import-Boilerplate, erleichtert die Wiederverwendung modularer Bibliotheken (ohne dass der eigene Code modular sein muss) und funktioniert reibungslos neben den bekannten import-Deklarationen. Für Einsteiger oder auch für Anwender des Prototypings in JShell sinkt die Hürde, weil sie nicht mehr wissen müssen, in welchem Paket sich einzelne Typen befinden. In Szenarien mit transitiven Modulabhängigkeiten (zum Beispiel java.sql, java.xml) vereinfacht sich die Nutzung zusammengehöriger APIs spürbar.

import module java.base;

List xs = List.of("a", "b");
Path p = Path.of("data.txt");
// List/Map/Stream/Path sind ohne einzelne Paket-Imports nutzbar

JEP 512 – Compact Source Files & Instance-main (Final in JDK 25)

Wir können jetzt in einer einzelnen Java-Datei viel schlanker kleine Programme abspeichern und ausführen. Ziel ist eine sanfte Einstiegskurve: Grundkonzepte zuerst, Programmieren-im-Kleinen ohne überflüssige Zeremonie. Bei wachsender Komplexität lässt sich der Code nahtlos zu Klassen/Packages/Modulen ausbauen. Gegenüber den Previews wird das Feature finalisiert und umbenannt (aus simple wird compact). Die neue IO-Klasse liegt nun in java.lang und wird damit implizit importiert, ihre statischen Methoden aber nicht. Außerdem basiert IO jetzt auf System.out/System.in statt java.io.Console.

// > java Main.java
void main() {
    IO.println("Hello, World!");
}

JEP 513 – Flexible Constructor Bodies (Final in JDK 25)

Konstruktoren dürfen nun Anweisungen vor dem Aufruf von super(...) oder this(...) enthalten. Diese Prolog-Phase dient beispielsweise zur Validierung von Argumenten, zum Initialisieren eigener Felder, ohne das entstehende Objekt anderweitig zu referenzieren, oder zum Transformieren von Inputwerten. Danach folgt der gewohnte Epilog. Das macht viele Konstruktoren natürlicher (z. B. fail-fast) und erhöht die Sicherheit, weil Unterklassen-Felder vor einem möglichen Zugriff durch Superklassen-Konstruktoren oder dort aufgerufene Methoden bereits gesetzt sind. Ziel ist es, überflüssige Beschränkungen zu entfernen und zusätzliche Garantien für einen vollständig initialisierten Objektzustand zu geben. Das umgeht die praktischen Probleme der bisherigen Regel „super() muss zuerst kommen“, durch die es zu unnötiger Arbeit, zu tückischen Initialisierungsfehlern bei mehreren Threads und zu Integritätsverletzungen kommen konnte.

JEP 507 – Primitive Typen in Patterns, instanceof und switch (3. Preview)

Dieser JEP macht Pattern Matching einheitlich für alle Typen, inklusive Primitive. Er erlaubt primitive Typmuster in allen Pattern-Kontexten (top-level und verschachtelt), erweitert instanceof auf Primitive (inklusive sichere, verlustfreie Umwandlungen) und lässt switch über alle primitiven Typen laufen (auch boolean, long, float, double). Ziel ist weniger Reibung und mehr Ausdrucksstärke: unsichere Casts und Boxing entfallen, da ein Pattern nur matcht, wenn die Konversion verlustfrei ist. Außerdem lassen sich Typmuster, instanceof und „safe casting“ semantics sauber aufeinander ausrichten.

// switch mit primitive type pattern
switch (x.getStatus()) {
  case 0 -> "okay";
  case 1 -> "warning";
  case 2 -> "error";
  case int i -> "unknown: " + i;   // zeigt unbekannten int-Status
}

// instanceof mit sicherer Konversion (matcht nur verlustfrei)
if (i instanceof byte b) { /* b nutzen */ }

// Record-Pattern mit sicherem Narrowing
if (json instanceof JsonObject(var map)
    && map.get("age") instanceof JsonNumber(int age)) {
  // nur wenn double → int verlustfrei passt
}

JEP 508 – Vector API (erneut Inkubator)

Die Vector-API erlaubt, Vektorberechnungen in Java auszudrücken, die der HotSpot-Compiler zu nativen SIMD-Instruktionen (x64: SSE/AVX, AArch64: NEON/SVE) kompiliert – mit stabilerer Performance als rein skalare Implementierungen. In JDK 25 ist diese API erneut im Inkubatorstatus, da man noch auf die Implementierung von Value Classes als Grundlage für die Vector API wartet. Neu sind:

• VectorShuffle ↔ MemorySegment-Zugriff
• Anbindung nativer Mathe-Bibliotheken über die FFM-API statt HotSpot-C++-Code (wartungsärmer)
• Auto-Vektorisierung von Float16-Operationen (Add/Sub/Mul/Div/Sqrt/FMA) auf unterstützten x64-CPUs.

Ziel ist eine klare, plattform-agnostische API mit verlässlicher Abbildung auf Vektorbefehle und „graceful degradation“.

Das waren 8 der insgesamt 18 neuen JEPs. Die anderen, die weniger für Entwicklerinnen und Entwickler relevant, aber trotzdem spannende Themen sind, schauen wir uns in einem zweiten Post an. Zusätzlich sind die vielen kleineren Neuerungen, für die es keine JEPs gibt, in den Release-Notes zum Nachlesen. Änderungen am JDK (Java Klassenbibliothek) wie die Stable Values oder Structured Concurrency kann man sich zudem über den Java Almanac anzeigen lassen.

(mdo)