Kolumne: EE Insights

Jakarta EE 8: Eine kritische Auseinandersetzung mit dem ersten Java-EE-Nachfolger

Christian Kaltepoth

Am 10. September war es endlich so weit. Der Tag, auf den die Community lange gewartet hatte, war endlich gekommen. Fast zwei Jahre nach der Geburt des Eclipse-EE4J-Projekts hat die Eclipse Foundation mit Jakarta EE 8 das erste offizielle Release des Java-EE-Nachfolgers freigegeben. In der neuen Kolumne „EE Insights“ hält uns Christian Kaltepoth auf dem Laufenden und versorgt uns mit Insider-Wissen aus dem Jakarta-EE-Universum.

Der Weg zu diesem Ziel war allerdings sehr steinig. Das zeigt vor allem der Blick auf den Kalender. Schließlich hat Oracle bereits vor genau zwei Jahren angekündigt, Java EE an die Eclipse Foundation zu übergeben. Das war damals natürlich eine sehr erfreuliche Nachricht, mit der niemand so wirklich gerechnet hat. Da Oracle die Arbeit an Java EE zwischenzeitlich komplett ausgesetzt hat, lag zuvor sogar die Vermutung nahe, dass es mit Java EE zu Ende gehen könnte. Daher war die Ankündigung einer Weiterentwicklung unter dem Dach der Open-Source-Organisation natürlich extrem positiv aufgenommen worden.

Allerdings wurde die Community zu diesem Zeitpunkt vielleicht sogar etwas zu optimistisch. Viele hofften damals, dass die Arbeit an Java EE nach dem Transfer zeitnah wieder aufgenommen werden würde und somit auch in absehbarer Zeit mit neuen Releases zu rechnen sei. Als allerdings klar wurde, dass der Transfer zur Eclipse Foundation ein äußerst aufwendiger und vor allem zeitraubender Prozess werden würde, schien die Hoffnung auf schnellen Fortschritt zu schwinden. Vor allem die endlosen Diskussionen um Marken- und Namensrechte waren dabei äußerst langwierig. In der ganzen Zeit war echte Arbeit an den Spezifikationen nicht wirklich möglich. Stattdessen stand in den letzten zwei Jahren der eigentliche Transfer der Projekte, die Klärung der rechtlichen Frage und die Bildung der neuen Organisationsstruktur im Fokus. Das war vor allem für diejenigen deprimierend, die schon sehr früh bei der Weiterentwicklung helfen wollten, jedoch keine wirkliche Möglichkeit dazu bekamen und immer nur als Antwort erhielten, sie müssten noch abwarten, bis alle offenen Punkte bezüglich der Weiterentwicklung geklärt seien.

Auf in die Zukunft

Und wo stehen wir heute? Jakarta EE 8 wurde gerade veröffentlicht. Das heißt vor allem, dass die Eclipse Foundation eine erste Version des Java-EE-Nachfolgers freigegeben hat, welche vollständig aus den entsprechenden Eclipse Projekten hervorgegangen und durch alle Phasen des neuen Jakarta-EE-Spezifikationsprozesses gelaufen ist. Ein echter Stapellauf für das neue Jakarta EE. Es scheint so, als würde Jakarta EE nun endlich auf eigenen Beinen stehen und könne den Blick nach vorne wenden.

Trotzdem ist dieses Release aus technischer Sicht natürlich extrem ernüchternd. Zwar wurde Jakarta EE von einer neuen Organisation und nach neuen Regeln und Prozessen veröffentlicht, jedoch entspricht der rein technische Stand exakt dem von Java EE 8, welches bereits 2017 der Öffentlichkeit vorgestellt wurde. Und wenn man ehrlich ist, war schon Java EE 8 nicht gerade ein großes Release. Denn im Jahr 2016 hatte Oracle auf der JavaOne-Konferenz verkündet, einen nicht gerade kleinen Anteil der geplanten Features aus dem Release-Plan zu streichen. Damals waren zwar auch eine ganze Reihe neuer Punkte in den Plan für Java EE 8 aufgenommen worden, allerdings hat es dann letztendlich fast kein neues Feature in das finale Release geschafft. Das war zwar sehr enttäuschend, allerdings war die Community zu diesem Zeitpunkt froh, dass es überhaupt ein Release gab.

Es wird also höchste Zeit, dass sich Jakarta EE weiterentwickelt und vor allem die Themen angeht, auf welche die Community schon seit Jahren wartet. Kandidaten gibt es mehr als genug. Das MicroProfile-Projekt hat beispielsweise bereits in vielen Bereichen vorgelegt. Themen wie Health Checking, Configuration und Fault Tolerance stehen schon lange auf der Wunschliste der Java Enterprise Community. Aber auch die schon lange ausstehende bessere Integration von CDI in die verschiedenen Bereiche der Plattform ist längst überfällig. Darüber hinaus hat die Community bereits diverse Vorschläge zusammengetragen, die man theoretisch auf die Tagesordnung setzen könnte.

Startschwierigkeiten

Das Problem an der Sache: Leider fehlen bis heute noch diverse Voraussetzungen, die erst erfüllt werden müssen, bevor es so richtig weiter gehen kann. Die Liste ist leider ziemlich groß. Zum einen wäre da die Namespace-Problematik. Da es der Eclipse Foundation nicht erlaubt ist, Jakara EE im altbekannten javax-Namespace weiterzuentwickeln, ist ein Wechsel in den neuen jakarta-Namespace unvermeidbar. Die Problematik und mögliche Strategien für eine Umsetzung dieser Umbenennung wurde in den vergangenen Monaten ausgiebig diskutiert. Die Vor- und Nachteile der verschiedenen Variante sind allseits bekannt. Allerdings ist bis jetzt keine Entscheidung darüber gefallen, welches der Verfahren denn nun angewendet wird. Wird Jakarta in einem großen Refactoring sämtliche Packages umbenennen oder doch einen inkrementellen Weg gehen, bei dem nach und nach nur die Packages umbenannt werden, die auch wirklich Änderungen an der API enthalten? Die finale Entscheidung darüber steht leider schon seit vielen Monaten aus. Natürlich ist die Hoffnung der Community, dass dieser Entschluss nach dem Jakarta EE 8 Release nun endlich gefällt wird. Dann kann dieses wichtige Thema, welches hauptsächlich aufgrund des Markenrechts zum Problem wurde und neben Jakarta EE auch die gesamte Java-Welt betrifft, endlich aus der Welt geschafft werden.

Unabhängig davon steht auch weiterhin ein großer Teil der Spezifikationsdokumente nicht zur Verfügung. Diese wurden angeblich schon vor einigen Monaten von Oracle an die Eclipse Foundation übergeben. Allerdings sind sie bisher nicht bei den jeweiligen Projekten angekommen. Laut Aussage der Eclipse Foundation sollten die Dokumente durch das IP-Team der Foundation lediglich noch einmal grob geprüft werden, bis sie dann für die Veröffentlichung in den Source-Code-Repositorys freigegeben werden. Leider ist dies aber bis heute nicht geschehen. Eine mögliche Erklärung dafür ist, dass die Dokumente absichtlich zurückgehalten wurden, um den Zeitplan für das Jakarta EE 8 Release nicht zu gefährden. Für dieses Release hatte man nämlich bereits beschlossen, lediglich „Boilerplate Specifications“ zu veröffentlichen, die nur die grobe Struktur der eigentlichen Dokumente enthalten, aber keinen echten Inhalt. Dass dies lediglich eine Notlösung war, ist offensichtlich. Hätte die Eclipse Foundation kurz vor dem geplanten Release von Jakarta EE 8 noch echte Spezifikationstexte zur Verfügung gestellt, wäre kurzfristig noch viel Arbeit auf die Projekte zugekommen. Vor allem die diversen neuen Namen der Spezifikationen in die Texte einzubauen, hätte vermutlich bedeutet, dass der ursprünglich anvisierte Zeitplan nicht zu halten gewesen wäre. Falls dieser Umstand also wirklich der Grund für die Verzögerung bei der Bereitstellung der Texte war, würde jetzt nach dem Release also nichts mehr gegen eine Veröffentlichung der Dokumente sprechen.

Die Dokumente selbst sind für die Projekte von enormer Wichtigkeit. Neue Funktionen und Präzisierungen der Spezifikationen betreffen in den meisten Fällen sowohl das API (also die Klassen, Interfaces, Javadocs, etc.) als auch die Spezifikationsdokumente und das TCK. Nur wenn alle drei Artefakte ordnungsgemäß angepasst werden können, kann sinnvoll weitergearbeitet werden. Was passiert, wenn dies nicht möglich ist, sieht man sehr gut an JAX-RS. Als eines der ersten Projekte hat JAX-RS bereits vor einigen Monaten mit dem Java SE Bootstrapping API ein neues Feature erarbeitet. Aufgrund der fehlenden Spezifikationstexte existiert diese Funktion allerdings bisher nur in dem API. Alle übrigen Anpassungen müssen dann irgendwann nachgepflegt werden, sobald das Projektteam dazu in der Lage ist. So türmt sich natürlich schnell Arbeit auf, die irgendwann nachgeholt werden muss.

Divide et impera

Auch im Bereich des TCK gibt es noch Baustellen. Zum aktuellen Zeitpunkt ist das Jakarta EE TCK ein einziges gigantisches Repository und enthält knapp 4,6 Millionen Codezeilen. Das ist vor allem aus organisatorischen Gründen problematisch. Zu Zeiten des JCP waren die Spezifikationen für ihre eigenen TCKs verantwortlich, welche dann alle zum Java EE CTS zusammengefasst wurden. Dieses daraus entstandene TCK-Paket ist als Ganzes zur Eclipse Foundation migriert worden und trägt heute den Namen Jakarta EE TCK. Zukünftig wäre es aber deutlich sinnvoller, wenn jedes Spezifikationsprojekt ein eigenes Repository mit den relevanten Teilen des TCKs unter seiner Kontrolle hätte. Nur so kann das Projektteam effizient arbeiten und das TCK Schritt für Schritt erweitern.

Von dieser optimalen Lösung ist Jakarta EE allerdings noch weit entfernt. Stattdessen scheint das TCK aktuell ein eher geschlossenes Projekt zu sein. Obwohl die über 330 Commits zeigen, dass aktiv am TCK gearbeitet wird, so findet doch kaum nennenswerte öffentliche Kommunikation auf der Mailingliste statt. Außerdem scheint hauptsächlich Oracle am TCK zu arbeiten, was sich aber auch damit erklären lässt, dass Oracle am vertrautesten mit diesem ist und daher zumindest aktuell noch einen Großteil der Arbeit übernimmt. Trotzdem muss hier dringend eine Lösung gefunden werden. Sollten zukünftig alle Änderungen am TCK per Pull Requests in ein einziges Repository übertragen werden müssen, so würde dieses schnell zum Flaschenhals werden und weitere Fortschritt würde blockiert. Leider ist das Aufteilen des TCKs aber eine durchaus nicht einfache Aufgabe, die sicherlich auch ihre Zeit benötigt. Welcher Weg auch immer für die Zukunft des TCKs gewählt wird, erste Schritte sollten zeitnah erfolgen, damit dieses Thema weiter vorangebracht werden kann.

Trotz all dieser Punkte sei trotzdem noch einmal erwähnt, dass das Jakarta EE Release ein großer Meilenstein und eine enorme Leistung aller Beteiligten ist. Allerdings muss auch klar gesagt werden, dass die Jakarta Community noch weit davon entfernt ist, sich auf die eigentliche Weiterentwicklung der Spezifikationen konzentrieren zu können. Es bleibt zu hoffen, dass nun endlich damit begonnen werden kann, die letzten Blockaden zu beseitigen und dann optimistisch in die Zukunft zu blicken.

Geschrieben von
Christian Kaltepoth
Christian Kaltepoth
Christian Kaltepoth arbeitet als Senior Developer bei ingenit GmbH & Co. KG in Dortmund. Sein Schwerpunkt ist die Entwicklung von webbasierten Unternehmensanwendungen auf Basis von Java-EE-Technologien. Darüber hinaus ist er in mehreren Open-Source-Projekten wie Apache DeltaSpike, Rewrite, PrettyFaces und Togglz aktiv. Er ist Mitglied der JSR 371 Expert Group und ein regelmäßiger Sprecher auf Konferenzen.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: