„Gut Ding will Weile haben“, sagt der Volksmund. Und das gilt sicherlich auch für die IT-Branche. Jeder von uns weiß, dass Zeitpläne nicht selten zu optimistisch sind. Und was fast jede*r Entwickler*in aus dem Alltag kennt, kommt auch bei großen Projekten vor, beispielsweise bei Jakarta EE.

Aber die guten Nachrichten vorweg: Nachdem das geplante Releasedatum für Jakarta EE 9 bereits zweimal verschoben wurde, ist es nun endlich soweit. Jakarta EE 9 hat das Licht der Welt erblickt. Obwohl wir alle doch länger warten mussten als gehofft, ist die neue Version der beliebten und weitverbreiteten Plattform für Java-Enterprise-Projekte nun endlich da. Um die außergewöhnliche Bedeutung und die enorme Tragweite dieses Releases besser einordnen zu können, muss man aber weiter vorne anfangen.

Seit Ende 2017 wird Java EE unter dem Dach der Eclipse Foundation weiterentwickelt. Mit der Migration von Oracle zur Eclipse Foundation ging auch die Umbenennung in Jakarta EE einher. Die Tatsache, dass Java EE einen neuen Namen bekommen sollte, war damals eher kritisch gesehen worden. Zu groß war die Angst, ein neuer Name könnte den Eindruck erwecken, es würde sich um eine ganz andere und vor allem inkompatible Plattform handeln. Aber es half alles nichts. Ein neuer Name war nicht zu vermeiden. Inzwischen haben sich die meisten an den neuen Namen gewöhnt, und Jakarta EE ist fast zu einem Synonym für Java EE geworden.

Der Umzug zur Eclipse Foundation war ein enormes Unterfangen, das leider einiges an Zeit benötigt hat. Schließlich ging es nicht nur darum, Quellcode von A nach B zu bewegen. Obwohl schon das bei über 13,5 Millionen Codezeilen und knapp 40 Projekten alles andere als trivial ist. Vor allem die notwendigen Strukturen zur Erarbeitung von Spezifikationen mussten erst noch geschaffen werden, bevor mit der eigentlichen Arbeit begonnen werden konnte. Dazu muss man wissen, dass die Eclipse Foundation zwar bereits viele Jahre Erfahrung mit Open-Source-Projekten hat, bisher allerdings noch nicht im Bereich der Spezifikationen tätig war. So mussten für Jakarta EE beispielsweise die verschiedenen Komitees erst geschaffen, deren Aufgaben definiert und die notwendigen Prozesse erarbeitet werden. Zudem hatte man sich vorgenommen, den bisher für Java EE zuständigen Java Community Process (JCP) nicht einfach zu kopieren, sondern aus seinen Schwächen zu lernen und einen moderneren und agileren Prozess für die Weiterentwicklung der Plattform zu schaffen. Aber dazu später mehr.

Im September letzten Jahres hat die Eclipse Foundation einen wichtigen Meilenstein erreicht. Mit der Veröffentlichung von Jakarta EE 8 wurde die erste offizielle Version von der Eclipse Foundation freigegeben. Das vollständig zu Java EE 8 kompatible Release war vor allem ein Stapellauf für den Spezifikationsprozess. Obwohl Jakarta EE 8 keine neuen Features mitbrachte und aus technischer Sicht eher eine Kopie von Java EE 8 war, hat die Eclipse Foundation doch zeigen können, dass die Komitees ihre Arbeit aufgenommen haben, der Spezifikationsprozess funktioniert, alle zur Plattform gehörenden Projekte Releases veröffentlicht haben und mit Eclipse GlassFish ein vollwertiger und nach Jakarta-EE-Regeln zertifizierter Anwendungsserver zur Verfügung gestellt werden konnte.

Jakarta EE 9

Aber zurück zum Thema dieses Artikels. Die Planung an Jakarta EE 9 begann bereits deutlich vor dem Release von Jakarta EE 8. Denn bereits früh stellte sich heraus, dass die Umbenennung von Java EE zu Jakarta EE lediglich ein sehr kleiner Teil des Problems war, das dadurch entstand, dass Oracle die alleinigen Rechte an der Marke Java besitzt. Ein weitaus größeres Problem war die Tatsache, dass Java EE schon immer den javax-Namensraum für Java-Pakete verwendet hat. Die javax-Paketnamen hatten im Java-Universum schon immer eine Sonderrolle. Ursprünglich war die Nutzung des Namensraums für Extensions gedacht, die nicht Teil der Klassenbibliothek des JRE waren. Im Laufe der Zeit ist diese Grenze allerdings immer wieder verwischt worden und einige javax-Pakete sind bis heute Bestandteil des JRE. Trotzdem galten für javax-Pakete schon immer sehr strenge Regeln. Um den Namensraum nutzen zu können, muss man den Weg über einen Java Specification Request (JSR) im Rahmen des Java Community Process gehen. Genau hier liegt aber auch das Problem. Da Jakarta EE nun unabhängig vom JCP weiterentwickelt wird, ist auch die Nutzung des javax-Namensraums nicht mehr möglich.

Bis Anfang 2019 hatte die Eclipse Foundation noch versucht, eine Einigung mit Oracle zu erzielen, die die weitere Nutzung der javax-Pakete erlauben würde. Leider vergeblich. Im Mai 2019 wurde bekannt, dass sich die Parteien nach vielen Monaten zäher Verhandlungen nicht auf einen Kompromiss einigen konnten. Ab diesem Zeitpunkt stand also fest, dass Jakarta EE nicht mehr mit den altbekannten javax-Paketnamen weiterentwickelt werden konnte.

Nachdem sich der Schock über diese Nachricht gelegt hatte, begann die Suche nach einer Strategie für die Migration in einen neuen Namensraum. Über längere Zeit wurden diverse Lösungsansätze mit verschiedenen Vor- und Nachteilen diskutiert. Letztlich entschied man sich für den sogenannten „Big Bang Proposal“. Dieser sah vor, die Paketnamen aller Spezifikationen auf einen Schlag in den neuen jakarta-Namensraum zu migrieren. Was zunächst nach der einzig sinnvollen Herangehensweise klingt, war aber nicht unumstritten. So gab es auch einige Befürworter für den alternativen „Incremental Proposal“, der eine schrittweise Migration einzelner Spezifikationen vorsah, und zwar nur dann, wenn sich einzelne Spezifikationen auch wirklich weiterentwickelt hätten. Diese Idee basierte auf der Tatsache, dass die Nutzung der javax-Pakete auch weiterhin möglich war, solange sich die darin enthaltenen Klassen nicht veränderten. So war es also theoretisch denkbar, einzelne Spezifikationen auf den neuen Namensraum zu migrieren, während unveränderte Spezifikationen weiterhin die javax-Paketnamen nutzen konnten. Das wäre zwangsweise auf einen Mix aus beiden Paketnamen hinausgelaufen. Zudem hätte sich die Migration aller Pakete über sehr lange Zeit und mehrere Releases hingezogen, was sicherlich ein deutlicher Nachteil dieser Variante gewesen wäre.

Letztlich entschied man sich doch dafür, alle Paketnamen gleichzeitig auf den neuen Namensraum umzustellen. Was zunächst nach einem vergleichsweise einfachen Refactoring klingt, ist in der Praxis natürlich ein enormer Aufwand. Zum einen bestand Java EE zu diesem Zeitpunkt aus einer historisch gewachsenen Codebasis von knapp 13,5 Millionen Codezeilen. Diese Zahl beinhaltet neben den Spezifikationen auch die diversen Referenzimplementierungen und das sogenannte Technology Compatibility Kit (TCK), mit dessen Hilfe Implementierungen auf die Kompatibilität mit den Spezifikationen geprüft werden können. Zum anderen wirkt sich die Anpassung der Paketnamen selbstverständlich auch auf die Spezifikationsdokumente und andere Artefakte aus.

Aufgrund des enormen Aufwands, den die Migration der Paketnamen für die Jakarta EE-Community bedeutete, wurde beschlossen, sich für Jakarta EE 9 vollständig auf diese Umstellung zu konzentrieren. Neue Funktionalität oder sogar neue Spezifikationen wurden nicht eingeplant. Was objektiv betrachtet eine gute Entscheidung war, ist natürlich trotzdem etwas ernüchternd. Bezüglich des Funktionsumfangs ist Jakarta EE 9 somit identisch zu Jakarta EE 8, das wiederum Java EE 8 aus dem Jahre 2017 entspricht.

Der Zeitplan für Jakarta EE 9 war ursprünglich sehr optimistisch. Der erste durch das Jakarta EE Platform Project veröffentlichte Releaseplan sah die Veröffentlichung im Juni 2020 vor. Dieser doch recht enge Zeitplan war schon von Anfang an als „sportlich“ bezeichnet worden. Spätestens als klar wurde, dass es nicht alle Spezifikationen schaffen würden, im Februar die geplanten ersten Vorabversionen zu veröffentlichen, war abzusehen, dass der Wunschtermin nicht zu halten sein würde. Immerhin hat es im Juni dann mit einem Meilenstein der Plattform funktioniert. Das Datum für die Veröffentlichung von Jakarta EE 9 wurde folglich auf den September verschoben. Der September wurde vermutlich auch deshalb anvisiert, weil das Release damit exakt ein Jahr nach Jakarta EE 8 erschienen wäre. Aber leider konnte auch dieser Termin nicht gehalten werden. Anfang September wurde er noch einmal auf Mitte November verschoben.

Glücklicherweise hat es mit diesem Termin dann funktioniert. Am 20. November endete die finale Abstimmung im Jakarta EE Specification Committee mit einem eindeutigen Ergebnis. Alle zehn Mitglieder stimmten für die Veröffentlichung der Plattform. Trotz einiger Verzögerungen hat die Jakarta-EE-Community ihr Ziel erreicht und mit Jakarta EE 9 die erste Version der Plattform im neuen jakarta-Namensraum veröffentlicht.

Anwendungsserver

Mit dem Release der Jakarta-EE-9-Spezifikation ist ein wichtiger Schritt getan. Trotzdem ist die Spezifikation ohne Anwendungsserver, die diese implementieren, nicht viel wert. Damals, zu Zeiten von Java EE, erschien mit jeder Version der Plattform auch gleichzeitig die Referenzimplementierung GlassFish. Erst viele Monate später zogen dann die Hersteller anderer Anwendungsserver nach. Daher stellt sich die Frage, wie der Stand diesbezüglich bei Jakarta EE 9 ist.

Streng genommen gibt es bei Jakarta EE die Sonderrolle der Referenzimplementierung nicht mehr. Trotzdem veröffentlichte die Eclipse Foundation zeitgleich zu Jakarta EE 9 auch Eclipse GlassFish 6.0.0, einen kompatiblen Anwendungsserver. Leider unterstützt dieser aktuell nur Java 8. Erst die nächste Version von Eclipse GlassFish soll mit Java 11 lauffähig sein. Einen konkreten Zeitplan gibt es bisher allerdings nicht.

Red Hat hat mit WildFly Preview 22 Alpha1 bereits eine erste Vorabversion mit Unterstützung für Jakarta EE 9 bereitgestellt. Technisch wird hier jedoch ein anderer Weg eingeschlagen als bei Eclipse GlassFish. Nur ein Teil der intern verwendeten Komponenten unterstützt den neuen Paketnamensraum bereits nativ. Beispiele hierfür sind Hibernate, Weld und Mojarra. Bei anderen Komponenten wird jedoch mit einem Trick gearbeitet. WildFly nutzt das Eclipse-Transformer-Projekt, das mittels Bytecodetransformation die Paketnamen austauscht. Mit diesem Trick lassen sich also Komponenten so anpassen, dass der neue Namensraum unterstützt wird, obwohl eigentlich die alten javax-Pakete verwendet werden. Das Verfahren funktioniert auch in die andere Richtung. Wird eine Anwendung deployt, die noch die alten javax-Paketnamen verwendet, werden die Klassen der Anwendung durch Eclipse Transformer so angepasst, als hätte man bereits auf Jakarta EE 9 umgestellt und gegen die neuen APIs kompiliert. Sicherlich ist das nur als Übergangslösung zu verstehen. Langfristig wird man eher auf eine vollständige Migration setzen. Allerdings hat Red Hat bereits klargestellt, dass der Fokus aktuell noch auf Jakarta EE 8 liegt. Das ist auch nachvollziehbar, da ein Großteil der Nutzer*innen noch nicht für eine Migration bereit ist und weiterhin auf eine ältere Version der Plattform setzt.

Auch Payara ist bereits erste Schritte in Richtung einer Unterstützung von Jakarta EE 9 gegangen. Ein vollständiger Support der Jakarta-EE-9-Plattform ist zwar erst mit der Payara Platform 6 geplant, jedoch bietet die kürzlich erschienene Version 5.2020.5 der Payara Server Community Edition eine Tech Preview, die bereits die neuen Paketnamen unterstützt. Intern setzt auch Payara dazu auf das Eclipse-Transformer-Projekt. Erkennt Payara beim Deployment die Verwendung der neuen jakarta-Paketnamen, werden die entsprechenden Klassen so transformiert, als wäre die Anwendung gegen das Jakarta EE 8 API kompiliert worden. Dieser Trick funktioniert nur deshalb, weil die APIs von Jakarta EE 8 und 9 mit Ausnahme der Paketnamen exakt identisch sind. Auch hier zeigt sich wieder, dass es eine gute Idee war, mit Jakarta EE 9 das API ansonsten unverändert zu lassen, da dieser Prozess sonst nicht möglich gewesen wäre. Trotzdem handelt es sich nur um ein Preview-Feature. Volle Jakarta-EE-9-Unterstützung wird es erst in Generation 6 der Payara Platform geben, für die ein erster Milestone noch für dieses Jahr angekündigt ist.

Auch IBM arbeitet bereits intensiv daran, den Support von Jakarta EE 9 in Open Liberty voranzutreiben. Mit der aktuellen Betaversion von Open Liberty 20.0.0.12 werden bereits viele Jakarta-EE-9-Spezifikationen nativ unterstützt. Intern verwendet auch Open Liberty Eclipse Transformer. Das ist auch nicht weiter verwunderlich, da ein Großteil des Eclipse-Transformer-Projekts von zwei IBM-Mitarbeitern geschrieben wurde.

Neben den bisher genannten Anwendungsservern gibt es auch eine spezielle Klasse von Servern, die auf jeden Fall erwähnt werden sollte. Die sogenannten Servlet-Container implementieren lediglich einen sehr kleinen Teil von Jakarta EE. Der bekannteste von ihnen, Apache Tomcat, gilt dabei als meistverbreiteter Java-Anwendungsserver der Welt. Apache Tomcat plant mit Version 10 volle Unterstützung für die entsprechenden Spezifikationen aus Jakarta EE 9, vor allem für Jakarta Servlet 5.0. Der aktuelle Meilenstein 10.0.0-M10 macht bereits einen sehr stabilen Eindruck. Wobei man natürlich beachten muss, dass ein Servlet-Container einen sehr viel spezielleren Fokus hat und die Migration auf die neuen Paketnamen somit deutlich schneller abgeschlossen werden kann als bei einem vollständigen Jakarta-EE-Anwendungsserver.

Anwendungsmigration

Jakarta EE 9 ist also veröffentlicht, und die diversen Anbieter von Anwendungsservern sind auf dem besten Weg, die neue Version der Plattform auch zu unterstützen. Da stellt sich die Frage, wie es bei den Anwendungen aussieht. Welche Herausforderungen kommen auf die Entwickler*innen zu, wenn es darum geht, die eigenen Anwendungen zu migrieren?

Auf den ersten Blick wirkt eine Migration auf Jakarta EE 9 recht einfach. Schließlich geht es hauptsächlich um die Paketnamen, sodass die Umstellung im einfachsten Fall mit einfachen Suchen und Ersetzen erledigt ist. Natürlich muss man noch die Version des API in seiner pom.xml anpassen und eventuell die Namespaces in XML-Dateien ändern, aber damit hat man zumindest für den eigenen Code die Umstellung bereits abgeschlossen.

Leider gibt es aber noch einen anderen Punkt, den es zu beachten gilt. Viele Projekte nutzen gleich eine ganze Reihe weiterer Frameworks oder Bibliotheken, die mit in die eigene Anwendung verpackt werden. Zumindest in einigen Fällen verwenden auch diese wiederum das Java EE bzw. Jakarta EE API und sind somit von der Migrationsproblematik betroffen. Interfaces wie javax.servlet.Servlet oder javax.servlet.Filter sind beispielsweise von großer Bedeutung für viele Open-Source-Bibliotheken.

All diese Projekte müssen also früher oder später auch auf die neuen Paketnamen migriert werden. In diesen Fällen ist man natürlich stark von den konkreten Migrationsplänen der einzelnen Projekte abhängig. Und besonders für Bibliotheken und Frameworks ist die Umbenennung eine große Herausforderung. Schließlich migrieren nicht alle User gleichzeitig auf die neue Version der Plattform. Man muss also zumindest eine gewisse Zeit lang sowohl die alten als auch die neuen Paketnamen unterstützen, was sich oft nur mit der parallelen Pflege zweier Entwicklungszweige lösen lässt. Der daraus resultierende Mehraufwand könnte vor allem für Open-Source-Projekte, die hauptsächlich von Freiwilligen entwickelt werden, nicht leicht zu stemmen sein.

Für die eigenen Anwendungen kann man sich somit glücklich schätzen, wenn die Abhängigkeiten möglichst minimal gehalten sind und man von dieser Problematik nicht ganz so stark betroffen ist. Fest steht allerdings, dass die Migration besonders im Fall von Drittanbieterbibliotheken und -Frameworks die gesamte Java-Welt noch einige Zeit beschäftigen wird.

Eine Retrospektive

Jakarta EE 9 ist das zweite offizielle Release der Plattform unter der Schirmherrschaft der Eclipse Foundation. Ein guter Zeitpunkt, um ein Fazit zu ziehen. Wie gut hat die Organisation bisher funktioniert? Hat man das angestrebte Ziel erreicht und einen moderneren und agileren Prozess für die Standardisierung der Plattform gefunden? Wie gut funktioniert die Zusammenarbeit zwischen den beteiligten kommerziellen Anbietern und der Open-Source-Community?

Auffällig ist in erster Linie, dass der Termin für Jakarta EE 9 mehrfach verschoben wurde. Hier stellt sich die Frage, wie es dazu kommen konnte. Die Ursachen sind allerdings vielfältig. Besonders die komplexen Abhängigkeiten zwischen den verschiedenen Spezifikationen waren dabei ein enormer Aufwandstreiber. Da die diversen APIs zum größten Teil aufeinander aufbauen, konnte die Arbeit nicht beliebig parallelisiert werden. Stattdessen war man oft darauf angewiesen, auf das Release einer anderen Spezifikation zu warten, bevor es mit der Arbeit weitergehen konnte. Zudem kam es oft zum altbekannten Henne-Ei-Problem zwischen den Spezifikationen, dem TCK und den Implementierungen.

Positiv aufgefallen ist vor allem die Tatsache, dass es viele neue Entwickler*innen gab, die bei der Arbeit an Jakarta EE 9 unterstützen wollten. Obwohl das ein extrem gutes Zeichen ist, bringt es ein Problem mit sich, das viele von uns aus dem Berufsalltag kennen. Neue Kolleg*innen sind nur selten sofort einsatzbereit, sondern müssen erst über eine gewisse Zeit eingearbeitet werden. Besonders bei extrem großen und komplexen Projekten, wie beispielsweise dem Jakarta EE TCK, braucht das seine Zeit. Zudem muss man beachten, dass sich die Koordination zwischen Mitarbeiter*innen verschiedenster Firmen und Freiwilligen aus der Community deutlich schwieriger gestaltet als zu Zeiten von Java EE. Damals ist die Arbeit fast ausschließlich von Oracle geleistet worden, was für die Koordination zwischen verschiedenen Workstreams sicherlich einfacher war. Trotzdem ist es ein gutes Zeichen, dass sich zunehmend verschiedene Parteien an der Weiterentwicklung der Plattform beteiligen.

Nicht zuletzt hat auch die Corona-Pandemie dazu beigetragen, dass der Zeitplan nicht gehalten werden konnte. Viele hatten in dieser Zeit mit enormen persönlichen und beruflichen Herausforderungen zu kämpfen, sodass die Energie für weiteres Engagement in Jakarta EE gefehlt hat.

Eine weitere zentrale Frage ist, wie gut der neue Spezifikationsprozess funktioniert hat, der für Jakarta EE definiert wurde. Streng genommen wurde er bereits bei Jakarta EE 8 angewendet. Allerdings wurde Jakarta EE 8 damals ohne echte Spezifikationsdokumente finalisiert, sodass von einer echten Anwendung des Prozesses nicht wirklich gesprochen werden kann. Das ursprüngliche Ziel des neuen Prozesses war es, den als schwerfällig geltenden Java Community Process durch ein moderneres und agileres Verfahren zu ersetzen. Aber ist das wirklich geglückt?

Vergleicht man den Jakarta EE Specification Process (JESP) mit der aktuellen Version des Java Community Process, fällt eine ganze Reihe von Ähnlichkeiten auf. Auch wenn es sich um einen neuen und eigenständigen Prozess handelt, scheinen die Phasen im Lebenszyklus einer Spezifikation und die diversen Abstimmungen zu bestimmten Zeitpunkten recht ähnlich zu sein. Einen fundamental unterschiedlichen Charakter, wie beispielsweise beim Vergleich des Wasserfallmodells mit agilen Prozessen, findet man zumindest nicht. Das muss aber kein schlechtes Zeichen sein. Auch im JCP gab es Spezifikationen, die in wenigen Monaten erstaunliche Ergebnisse erzielt haben.

Aktuell scheint noch problematisch zu sein, dass der neue Prozess recht kompliziert wirkt. Diese Einschätzung, die auch von ehemaligen Specification Leads aus Zeiten des JCP geäußert wurde, scheint berechtigt zu sein. Der Prozess für Spezifikationsprojekte beinhaltet mehrere Pull Requests mit langen Checklisten, diverse E-Mails an verschiedene Parteien und mehrere Abstimmungen. Vor allem in der Anfangszeit waren die Details zu den genauen Abläufen über mehrere Wikis und Webseiten verstreut, was die Arbeit nicht gerade einfacher machte. Das hat sich in jüngster Zeit deutlich verbessert. Inzwischen gibt es mit dem Specification Operations Guide einen guten Überblick über die diversen Aspekte des Gesamtprozesses. Zudem ist man sich des Problems bewusst und arbeitet aktuell daran, Möglichkeiten zur Vereinfachung des Prozesses zu finden.

Die nächsten Schritte

Und was ist für die Zukunft geplant? Nach dem Release ist schließlich vor dem Release. Während für die Hersteller von Anwendungsservern die Arbeit jetzt erst richtig losgeht, um möglichst bald Jakarta EE 9 vollständig zu unterstützen, blickt die Jakarta-EE-Community bereits in die Zukunft. Aktuell ist es zu früh, um von konkreten Plänen zu sprechen, allerdings werden die ersten Ideen bereits aktiv diskutiert.

Es gilt als sehr wahrscheinlich, dass das nächste Release Jakarta EE 9.1 heißen wird. Wie der Name bereits andeutet, wird es sich nicht um eine Major-Version handeln, sondern um ein vergleichsweise kleines Release. Als Zeithorizont hat man bisher grob das Frühjahr nächsten Jahres anvisiert. Aber auch das ist bisher nur als Vorschlag und Diskussionsgrundlage zu verstehen. Nachdem die Community leider doch länger auf Jakarta EE 9 warten musste, ist es erfreulich zu hören, dass ein weiteres Release vergleichsweise schnell zu erwarten ist. Allerdings war auch Jakarta EE 9 ursprünglich sehr optimistisch geplant, was sich später als Fehler herausstellte.

Auch der Scope für das Release steht noch nicht fest und befindet sich aktuell in der Abstimmung. Man kann aber bereits erahnen, um welche wesentlichen Punkte es gehen wird. Einer der wichtigsten Aspekte ist der Support für Java 11. In diesem Bereich möchte man sicherlich nachholen, was bei Jakarta EE 9 nicht geklappt hat. Als Oracle im Oktober 2019 die ersten Ideen für Jakarta EE 9 vorstellte, plante man noch die Mindestvoraussetzung von Java 8 auf Java 11 anzuheben. Im Releaseplan wurde dann aber nur eine „Light-Version“ davon eingeplant. Diese sah vor, dass alle Spezifikationen auch weiterhin mit dem Source-Level 8 kompiliert werden müssen. Gleichzeitig sollten Anwendungsserver ihre Kompatibilität aber auf Basis von Java 11 zertifizieren, wobei Unterstützung von Java 8 nur optional gewesen wäre. Leider hat sich im Juli dieses Jahres herausgestellt, dass selbst dieses Ziel nicht erreichbar war, da es große Probleme mit den notwendigen Anpassungen am TCK und an Eclipse GlassFish gab. Daher wurde der Plan geändert und Jakarta EE 9 setzt somit, ähnlich wie seine Vorgänger, lediglich Java 8 voraus.

Es ist somit sehr wahrscheinlich, dass die Unterstützung von Java 11 einer der wesentlichen Punkte für Jakarta EE 9.1 sein wird. Ob das allerdings heißt, dass auch die Jakarta EE APIs gegen Java 11 kompiliert werden, oder ob von Anwendungsservern lediglich gefordert wird, dass sie Java 11 als Runtime unterstützen müssen, steht noch in den Sternen.

Ein weiteres Thema, das ebenso bereits für Jakarta EE 9.1 genannt wurde, ist bessere Unterstützung für das Java Platform Module System (JPMS), das sich inzwischen zu einem festen Bestandteil der Java-Plattform entwickelt hat. Bisher existieren nur wenige Spezifikationen, die bereits entsprechende Modulnamen in den APIs verankert haben. Denkbar wäre zumindest, das für alle Spezifikationen nachzuholen. Der Nachteil dieser Variante wäre allerdings, dass wieder ausnahmslos alle Spezifikationen neue Versionen veröffentlichen müssten. Und wie uns Jakarta EE 9 gelehrt hat, können vor allem die Abhängigkeiten untereinander hier wieder zu einem enormen Aufwand führen. Es stellt sich also die Frage, ob dieser Aufwand wirklich gerechtfertigt ist. Zudem setzen einige der existierenden Anwendungsserver aus historischen Gründen seit jeher auf OSGi, sodass bessere Unterstützung von JPMS vielleicht gar keinen echten Mehrwert bringt. Zumindest solange JPMS noch nicht von Jakarta-EE-Anwendungen genutzt werden kann. Dazu wäre aber noch deutlich mehr Arbeit auf Seite der Spezifikationen notwendig.

Für Entwickler*innen bleibt sicherlich eine der spannendsten Fragen, ob Jakarta EE 9.1 denn in funktionaler Hinsicht neue Features oder sogar neue Spezifikationen enthalten wird. Auch hier ist noch keine finale Entscheidung getroffen. Es wäre aber denkbar, neue Versionen existierender Spezifikationen aufzunehmen, falls sie den Zeitplan für das Release nicht gefährden. Einige Kandidaten stehen hierfür bereits bereit. So hat Jakarta RESTful Web Services, früher bekannt als JAX-RS, mit dem neuen Java SE Bootstrapping API bereits seit über einem Jahr ein neues Feature erarbeitet, das in die nächste Version einfließen könnte. Ähnliches gilt für die Jakarta-Servlet-Spezifikation, die mit der Unterstützung des SameSite-Attributs für Cookies kurz davor steht, ein lang ersehntes Feature endlich voll zu unterstützen.

Auch bezüglich neuer Spezifikationen hat sich bereits einiges getan. So stehen mit Jakarta MVC und Jakarta NoSQL bereits zwei Kandidaten fest und könnten theoretisch fester Bestandteil der Plattform werden. Ob das allerdings bereits mit dem aktuell in der Planung befindlichen Minor-Release umgesetzt wird, bleibt abzuwarten. Sicherlich wären aber neue Spezifikationen ein sehr positives Signal an die Community, die in den letzten Releases auf neue Funktionalität verzichten musste.

Fazit

Insgesamt lässt sich sagen, dass Jakarta EE 9 ein großes und sehr wichtiges Release für die gesamte Java-Welt ist. Vor allem, weil die Migration der Paketnamen langfristig auch Anwendungen betrifft, die gar keinen vollständigen Jakarta-EE-Anwendungsserver, sondern nur einen Servlet Container wie Apache Tomcat nutzen. Obwohl das Release insgesamt länger gedauert hat als ursprünglich geplant, ist es doch eine enorme Leistung und eine bemerkenswerte Kooperation vieler Parteien aus dem Java-Ökosystem.

Die Umstellung der Paketnamen auf den jakarta-Namensraum wird uns alle aber sicherlich noch einige Zeit beschäftigen. Dabei bleibt zu hoffen, dass die Java-Community diese Aufgabe in Zusammenarbeit gemeinsam bewältigt, damit die Plattform sich in Zukunft frei und ohne rechtliche Einschränkungen weiterentwickeln kann. Man darf sich aber nichts vormachen, denn ein gewaltiger Teil der notwendigen Arbeit liegt noch vor uns.

Zusätzlich bleibt zu hoffen, dass das nächste Jakarta-EE-Release nicht allzu lange auf sich warten lässt. Lange wurde der Java Community Process dafür kritisiert, träge und unflexibel zu sein. Es bleibt also zu hoffen, dass Jakarta EE hier eine andere Richtung einschlägt. Außerdem wäre es an der Zeit, neue Funktionalität zu liefern, nachdem die Community so lange warten musste. Man darf also gespannt sein, was der konkrete Plan für Jakarta EE 9.1 enthalten wird.