Ich bin mir nicht sicher, ob ich diese Neuigkeiten von Oracle bezüglich GraalVM richtig interpretiere und einordne. Wäre ich mir sicher, hätte die Überschrift beispielsweise „Oracle killt 70% von GraalVM“ gelautet, oder aber „Oracle JDK gleicht sich wieder OpenJDK an“ – je nach gewähltem Extrem der Interpretation. Aber die Wortwahl des Postings ist irgendwie verquast und Management-will-die-Neuigkeiten-nicht-klar-kommunizieren-artig. Finde ich. Auch das verlinkte Posting von 2022 das irgendwie damit zusammenhängen soll klärt die Sache nicht auf.
Ich beobachte das GraalVM-Universum ja schon einige Zeit – letztes Blog-Posting zu diesem Themenkomplex hier – weil ich die ganze Sache mindestens vom technischen Standpunkt aus für außerordentlich interessant halte, und außerdem der Use-Case „kleines Binary mit schnellem Startup“ für meine Swing-Windows-Hobby-Projekte von Vorteil wären – Konjunktiv, weil das bis heute in der (oder mindestens meiner) Praxis nicht mal ansatzweise funktioniert, aber halt in der Theorie. Konkurrierend zum „Native Image“-Feature hat Oracle ja schon vor einiger Zeit das „Project Leyden“ ins Leben gerufen, das durch Persistenzierung der JIT-Kompilate ein ähnliches Ergebnis bezüglich Startup- und Warmlaufzeiten zu erreichen. Das schien (und scheint weiterhin, wobei mit JDK 25 wohl gute Fortschritte erzielt wurden – muss ich auch irgendwann ™ mal anschauen) aber so ein typisches Mark-Reinhold-dauert-ewig-Projekt zu sein (vergleiche Modularisierung der JRE und Java-Modulsystem).
Ein paar Wendungen aus dem „Detachment“-Posting haben beinahe schon alarmierenden Charakter: „GraalVM for JDK 24 was the final GraalVM release licensed and supported as part of Oracle Java SE Products.“ oder auch „Oracle JDK 24 was the final release to include the experimental and optional Graal JIT.“ oder „GraalVM Early Adopter technology, including Native Image, is being discontinued for Java SE Product customers.“ oder „Oracle customers using the Graal JIT, either in a GraalVM distribution or as part of the integration in Oracle JDK 23 and 24, are encouraged to use the default C2 JIT instead.“
Auch alarmierend: der letzte Blog-Post des GraalVM-Teams stammt vom 11. März 2025 und befasste sich mit dem vorigen Java Release 24 – und das, obwohl die GraalVM-Hauptseite schon die Verfügbarkeit von GraalVM JDK 25 verkündet. Komische Sache.
Komisch auch: diverse Java-Newsletter haben den Oracle-Blogpost „einfach so“ ohne weiteren Kommentar und weitere Erläuterungen wiedergegeben – was allerdings auch dadurch erklärbar ist, dass die sich einfach als News-Aggregatoren verstehen und das Einordnen ihren Lesern überlassen.
Im dazugehörigen Reddit-Thread gibt es einige wenige nützliche Debattenbeiträge, die eher die Auffassung „schlecht kommuniziert von einer für den normalen Java-Nutzer unwichtigen Oracle-Untereinheit, die sich um das Produkt ‚Oracle JDK und Java SE‘ kümmert, das mehr oder weniger separat von OpenJDK und dem für Normalsterbliche relevanten Teil des Java-Ökosystems zu betrachten ist“ stärken.
Ich sage es mal so: wäre Oracle nicht Oracle, die schon regelmäßig in der Vergangenheit schlecht kommunizierte bis fragwürdige Entscheidungen rund um das Java-Ökosystem verbrochen hätten, man würde sich vermutlich gar keine Sorgen machen.
Im Moment würde ich aber eher einschätzen – oder besser vermuten, weil schon viel „educated guessing“ dabei ist – dass sich das Oracle-Annuncement tatsächlich weder auf GraalVM noch auf das Ökosystem rund um Graal-und-OpenJDK bezieht, sondern ausschließlich auf „Oracle JDK“ und „Oracle Java SE“ und deren bisheriger Graal-Integration und damit keine direkt ersichtliche Relevanz für die GraalVM-Nutzer wie Quarkus, Micronaut, Helidon, Spring und Konsorten hat. Trotzdem wäre es sehr vorteilhaft, wenn es mal ein vernünftig formuliertes Posting von der GraalVM-Seite geben würde. Denn mindestens ein Fragezeichen bleibt natürlich: die Formulierung im „Detachment“-Posting „The GraalVM team are transitioning to focus on non-Java Graal Languages including GraalPy and GraalJS.“ weist irgendwie schon auf eine Umstrukturierung der Entwicklungsschwerpunkte hin, und vielleicht ist das „Oracle Product Management“ ja der größte Geldgeber hinter dem GraalVM-Entwicklungsteam und es ergeben sich aus dieser Entscheidung längerfristige Folgen.
Zum Abschluss der Tipp an alle, die es bevorzugen, sich nicht um undurchsichtiges Oracle-Blabla zu kümmern und stattdessen „News from the bright side of Native Java“ zu lesen, empfehle ich diesen Blog-Beitrag von Bell Software zu deren „Liberica Native Image Kit“, der auf GraalVM basiert.