Java 25 / JDK 25 offiziell veröffentlicht

• Java 25 und seine Referenzimplementierung JDK 25 wurden offiziell veröffentlicht
• Diese Version enthält 18 neue JEPs (Java Enhancement Proposals)
• Wichtige Änderungen sind unter anderem Entfernung des x86-32-Bit-Ports, Scoped Values, Structured Concurrency und Verbesserungen bei Primitive Types

---

Java 25 / JDK 25: Offizielle Veröffentlichung

• JDK 25, also die Referenzimplementierung von Java 25, wurde offiziell als Version für den Produktionseinsatz veröffentlicht
• Am 15. August 2025 wurde mit Build 36 der zweite Release Candidate bereitgestellt; seitdem wurden keine kritischen (P1) Bugs gemeldet.
• Build 36 ist die finale GA-Version (General Availability) und kann auch in Produktionsumgebungen eingesetzt werden

• OpenJDK-Builds auf GPL-Basis werden offiziell von Oracle bereitgestellt; Build-Versionen weiterer Anbieter sollen ebenfalls in Kürze erscheinen

Offizieller OpenJDK-Download-Link

Wichtige Funktionen und Verbesserungen

Diese Veröffentlichung umfasst 18 JEPs (Java Enhancement Proposals)

• 470: PEM-basierte Kodierung kryptografischer Objekte (Preview)
• 502: Stable Values (Preview)
• 503: Entfernung des x86-32-Bit-Ports
• 505: Structured Concurrency (5. Preview)
• 506: Scoped Values
• 507: Unterstützung für Primitive Types in Patterns, instanceof und switch (3. Preview)
• 508: Vector API (10. Inkubator-Version)
• 509: JFR CPU-Zeit-Profiling (experimentelle Funktion)
• 510: Key Derivation Function API
• 511: Module-Import-Deklarationen
• 512: Compact Source Files und Instanz-main-Methoden
• 513: Flexible Constructor Bodies
• 514: Ahead-of-Time-Kommandozeilenoptimierung
• 515: Ahead-of-Time-Methodenprofiling
• 518: Kooperatives JFR-Sampling
• 519: Compact Object Headers
• 520: JFR Method Timing and Tracing
• 521: Generational Shenandoah

Neben den oben genannten JEPs enthält diese Veröffentlichung außerdem Hunderte kleinerer Funktionsverbesserungen und Tausende Bugfixes

Ausführliche Informationen zur Veröffentlichung und Details zu den JEPs finden sich auf der
OpenJDK-Projektseite zu JDK 25

[ahwjdekf]

Der alte Gaukler vom letzten Jahr ist nicht gestorben und kommt schon wieder, eoreolssigushigu, jetzt geht’s los … Warum tauchst du ständig wieder auf?

[click]

Die Funktion ist zwar schon in JDK 24 eingeführt worden, aber da Java meist nur als LTS eingesetzt wird, ist auch JEP 491: Synchronize Virtual Threads without Pinning beachtenswert, weil beim Verwenden des Schlüsselworts synchronized das Pinning-Phänomen bei virtuellen Threads verschwunden ist.
In der Praxis gab es bei Benchmarks mit virtuellen Threads häufig Fälle, in denen sie langsamer waren, und in den meisten davon war Pinning die Ursache.

[GN⁺]

Hacker-News-Kommentare

• Ich finde, es sollten mehr neue Programme in Java oder auf der JVM geschrieben werden; die Gründe für den Popularitätsverlust von Java in der Vergangenheit sind heute fast alle verschwunden, und inzwischen ist es ein sehr stabiles und ausgereiftes Ökosystem. Ein Clojure-Programm, das ich vor 10 Jahren geschrieben habe, läuft immer noch problemlos, während ein in TypeScript geschriebenes Programm schon nach 6 Monaten Wartung und Updates braucht.
  • Oracle ist dabei der größte Haken. Es ist lästig, bei Java ständig darauf achten zu müssen, nicht gegen Oracles EULA zu verstoßen. Mit OpenJDK ist das wohl in Ordnung, aber ich würde lieber einfach eine andere Sprache verwenden, ohne mir darüber Gedanken machen zu müssen. C# bietet ein ähnliches Umfeld wie Java, ohne dass man sich um Oracle sorgen muss. Statt zu lernen, wie man Java rechtssicher nutzt, wähle ich lieber gleich eine andere Sprache. Java ist auch nicht zwingend nötig, es gibt genug Alternativen.
  • Java ist in großen Backend-Systemen immer noch extrem beliebt und weit verbreitet. Es überrascht mich, dass hier offenbar nicht viele mit solchen Systemen arbeiten. In meiner Erfahrung begegnet mir Java fast immer.
  • Ich hoffe insgeheim, dass Kotlin und Compose Desktop-Apps auf der JVM wiederbeleben.
  • Der fortbestehende Risikofaktor für die Akzeptanz von Java ist aus meiner Sicht die zugehörige Kultur. Ältere Java-Entwickler und bestehende Java-Programme sind oft unnötig wortreich geschrieben, obwohl die Sprache selbst längst Funktionen hat, mit denen man ähnlich knapp wie in anderen modernen Sprachen schreiben kann. Trotzdem ist Java so groß, dass ich noch Veränderungspotenzial sehe.
  • Ich frage mich, ob das Clojure-Programm von vor 10 Jahren dank der JVM noch so gut läuft oder wegen der Eigenheiten von Clojure. Ich habe mit ClojureScript ähnliche Erfahrungen gemacht. Auch alte nbb-Skripte laufen direkt und ohne größere Probleme wieder an, höchstens muss man gelegentlich bei npm-Abhängigkeiten etwas nachbessern. In Python dagegen habe ich schon einen halben Tag mit Abhängigkeitsproblemen und venv-Verwaltung verloren.
• Java ist seit Langem eine erstaunlich solide technische Grundlage. Es ist nicht die attraktivste Sprache, aber sie zeigt immer Stabilität. Eine mit Java 1.4 gebaute App läuft auch unter Java 21 LTS gut, und bald will ich auf Java 25 upgraden. Java ist großartig.
  • Ich frage mich, wo Java heute stünde, wenn es nicht die hervorragenden Tools von JetBrains und das clevere Studentenprogramm gäbe.
  • Mit etwas Abstand, aber ich erinnere mich immer noch an die mit Java gebaute Gmail-App, die 2009 auf meinem Touch-Symbian-Handy lief. Wirklich niedlich und funktional gut nutzbar.
  • Meiner Erfahrung nach kann ich dem nicht voll zustimmen. Jedes Mal, wenn in mehreren Firmen eine JVM-Version angehoben wurde, gab es große Probleme und viel Nacharbeit sowie erneute Tests. Ich bin etwa bei Java 17~18 ausgestiegen, aber die Leute, mit denen ich arbeite, haben neue Versionen fast nie genutzt. 2022 musste in einem Projekt JVM 1.5 aktualisiert werden, und wichtige Third-Party-Bibliotheken unterstützten nur Versionen bis vor Java 1.7, was vieles erschwerte. Ich habe versucht, an den Quellcode zu kommen und selbst zu kompilieren, aber der Umfang wurde immer größer. Es war mühsam, weil ich mit dem Management nicht auf einen Nenner kam, und am Ende habe ich beschlossen, den Top-Tier-Client eines Fortune-10-Unternehmens zu verlassen. Soweit ich weiß, ist das System bis heute nicht aktualisiert worden.
  • Ich wollte schon länger mal wieder eine alte Swing-App ausprobieren und denke, dass ich sie ohne große Änderungen wiederbeleben könnte, also werde ich es wohl versuchen.
  • Die JVM und ihr Ökosystem lassen sich auch mit anderen Sprachen wie Scala und Clojure nutzen, was vielfältige und attraktive Einsatzmöglichkeiten eröffnet.
• Erstaunlich, dass es so lange gedauert hat, bis Parameterprüfung und -umwandlung vor dem super-Aufruf im Konstruktor erlaubt wurden. Das war für mich schon immer etwas, das der Intuition widersprach.
  • Ich nutze Java seit vor JDK 1.0, und das hat mich schon früher gestört, aber inzwischen habe ich mich daran gewöhnt und kenne die Umgehungen.
  • Wenn man den Validierungsschritt in einer static-Funktion für die super-Parameter genutzt hat, wurde er tatsächlich schon vor super aufgerufen, und der Compiler hatte damit kein Problem.
• Ich bin kein Java-Entwickler, aber das Modul-/Import-System gefällt mir persönlich nicht besonders. Syntax wie import * macht das Schreiben von Code zwar leicht, aber das Lesen deutlich schwerer, besonders für Entwickler, denen die Sprache oder Codebasis nicht vertraut ist. C# und Nim sind ähnlich, und ohne IDE kann ich das kaum lesen. Deshalb finde ich kurze Aliase wie in Python (import torch.nn.functional as F) besser.
  • Das Hauptproblem bei Imports in großen Codebasen ist: „Wo kam das her?“ Explizite Imports sind dafür zwingend nötig, besonders wenn Builds kaputtgehen oder Abhängigkeitsversionen unklar sind. In kleinen Codebasen ist es egal. Moderne Editoren blenden Imports ohnehin oft aus, also sieht man sie kaum direkt, und man springt per Klick oder Shortcut sofort zur Definition, deshalb achte ich selten stark auf Imports.
  • Ich glaube, die schlechte Erfahrung mit C# liegt daran, dass kein richtiges Visual Studio verwendet wurde. VSCode ist zwar gut, aber csproj- oder sln-Dateien würde ich niemals in VSCode öffnen. Übrigens kann man Visual Studio hier für 500 $ mit einer unbefristeten Lizenz kaufen und ohne separates Abo nutzen.
  • Ich verstehe die Beschwerde über Sprachkonstrukte nicht, die ohne IDE schwer zu durchschauen sind. Man schaut sich den Code doch in einer IDE an, also sehe ich darin kein Problem. Wer keine IDE nutzt, macht es sich selbst unnötig schwer. Und wenn man Code auf GitHub anschaut, analysiert man Referenzen meist ohnehin nicht tiefgehend, daher ist diese kleine Einbuße an Lesbarkeit vertretbar.
  • Soweit ich weiß, ist dieser Stil dafür gedacht, das Schreiben von Programmen in einer einzigen Quelldatei einfacher zu machen.
• Die neuen Funktionen sind auf der offiziellen OpenJDK-25-Seite gut zusammengefasst, und Java 25 ist ein LTS-Release.
  • Hoffentlich kommt der Tag schnell, an dem ich in 10 Jahren von 17 auf 25 migrieren muss.
• Rein subjektiv wirkt es auf mich so, als habe sich Java trotz seines Alters in den letzten 10 Jahren stetig weiterentwickelt, während C++ eher schwieriger geworden ist.
• Leider ist Structured Concurrency noch nicht vollständig veröffentlicht. Darauf freue ich mich sehr. Dafür ist die Ergänzung um Scoped Values willkommen; allein damit lässt sich Code in Java meiner Meinung nach schon in einem „Rails-artigen“ Stil strukturieren, ohne ständig God-Classes oder God-Objects zu missbrauchen.
  • Im Vergleich zur derzeit verwirrenden Situation bei C++, wo Funktionen ohne aktuelle Implementierung standardisiert werden, finde ich Javas schrittweises Vorgehen über Preview-Features deutlich besser.
  • Ich hoffe, Structured Concurrency fühlt sich nicht wie überzuckertes async/await an, sondern wie ein echter Fortschritt. Nach den Beispielen bin ich noch nicht überzeugt, aber ich will es weiter beobachten.
• Ich habe mich kürzlich zur Migration von JDK 8 entschlossen und bin direkt auf JDK 21 gegangen. Da 25 vor der Tür steht, habe ich mich statt für 17 für 21 entschieden. Meiner Ansicht nach war die Migration von 8 auf 11 am schwierigsten, weil dort das neue Modulsystem auftauchte; danach wird es einfacher. Den Proof of Concept habe ich mit jdk17 gemacht, und fast unverändert lief es auch unter jdk21 (nur guice brauchte ein Major-Upgrade). Nebenbei glaube ich, dass auch der Einsatz einer anderen JVM-Sprache statt Java geholfen hat.
  • Für unser Team war der Schritt von 8 auf 17 schwierig. Wir hatten viel Nicht-Offizielles wie sun-Pakete im Einsatz, und auch der Wechsel von javax zu jakarta war belastend. Wenn man diese Hürde einmal genommen hat, wirken 21 oder 25 leicht. Ich hoffe, dass es künftig einfacher sein wird als früher, kontinuierlich auf dem neuesten Stand zu bleiben.
  • Java 9 war der Python-3-Moment des Ökosystems, aber inzwischen fühlt es sich so an, als wäre alles problemlos bereinigt.
  • Zur Einordnung: Ich bin kürzlich von 17 auf 21 migriert und hatte überhaupt keine Probleme. Kleinere Themen gab es nur, als ich gleichzeitig Gradle angehoben habe (das ist im Kern ein anderes Problem).
• Die neuen Funktionen von Java 25 sind in diesem baeldung-Beitrag gut zusammengefasst.
• Mich interessiert, wie die rechtliche Lage bei der Nutzung von Java derzeit aussieht, sowohl für Open Source als auch kommerziell. Oracle bindet großartige Technologien wie Truffle an Java; ich würde gern wissen, wie sinnvoll der Einsatz in neuen Projekten ist.
  • OpenJDK ist de facto die direkt von Oracle kommende Version unter offener Lizenz. Wenn man Oracle nicht mag, kann man Versionen von anderen Anbietern wie der Eclipse Foundation, Microsoft oder Amazon verwenden. Die Langlebigkeit von Java ist ein Grund, warum alte Versionen wie 8/11 noch genutzt werden: Einmal geschrieben, läuft es wirklich sehr lange. Bei Features ist es langsamer als die Konkurrenz, aber für wichtige Entwicklung absolut ausreichend. Wenn man ohnehin von der JVM abhängt, würde ich Kotlin empfehlen (zumal Java immer noch keine nullable types hat und NullPointerException deshalb häufig ist). Wenn Kotlin nicht zusagt, ist auch C# gut. Trotzdem ist Java absolut brauchbar.
  • Nach heutigem Stand kann man bei Oracles Distribution im Grunde nur die jeweils aktuelle LTS-Version frei verwenden. Niedrigere Versionen stehen unter der OTN-Lizenz und sind nur für private Nutzung bzw. Entwicklung erlaubt, nicht für Produktion. Wenn man nicht unbedingt das Oracle-Branding braucht, hat man mit OpenJDK oder JDKs anderer Anbieter keine Lizenzsorgen.
  • OpenJDK ist vollständig Open Source, da muss man sich überhaupt keine Sorgen machen.
  • Wenn man etwas wie OpenJDK nutzt, ist man von Oracle-Problemen komplett unabhängig.
  • Solange man nicht selbst eine Java-Implementierung bauen und vertreiben will, spielen rechtliche Fragen praktisch kaum eine Rolle.