© PhotoStockPhoto/Shutterstock.com
Was bringt die neue Version von Jakarta EE?

Gut Ding will Weile haben


Nach über einem Jahr Entwicklungszeit ist vor wenigen Tagen nun endlich Jakarta EE 9 von der Eclipse Foundation veröffentlicht worden. Mit diesem Release wurde die lange angekündigte Umstellung der Paketnamen auf den neuen Namensraum durchgeführt. Grund genug, einen genaueren Blick auf die neue Version zu werfen und zu reflektieren, wie sich Jakarta EE unter dem Dach der Eclipse Foundation weiterentwickelt.

„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 [1] 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) [2] 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 Referenzi...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang