Kolumne: EE Insights

Jakarta EE: Noch keine Entscheidung aber Jakarta EE 8 in den Startlöchern

Christian Kaltepoth

Viel tut sich momentan bei der Java Enterprise Edition: der Umzug nach Eclipse, die Umbenennung in Jakarta EE, der neue Community-getriebene Prozess, die Konsolidierung und Weiterentwicklung der Standards. 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.

Manchmal vergeht die Zeit wie im Flug. Schließlich ist es jetzt schon drei Monate her, dass die Eclipse Foundation die Community über die gescheiterten Verhandlungen mit Oracle informierte. Als Folge daraus ist es Jakarta EE nun nicht mehr möglich, die Spezifikationen im altbekannten javax-Namespace weiterzuentwickeln. Nachdem nun einige Monate vergangen sind, hat sich wohl jeder mit dieser Situation abgefunden. Eigentlich hätte man sich eine bessere Lösung gewünscht, aber dieser Zug ist leider abgefahren. Die Situation ist, wie sie ist, und die Community muss nun nach vorne blicken.

Big-Bang Approach oder Incremental Approach?

Ursprünglich war geplant, möglichst schnell eine Strategie für den notwendigen Wechsel auf den jakarta-Namespace zu finden. Die verschiedenen Alternativen wurde anfänglich heftig auf den Mailinglisten diskutiert. Mittlerweile sind die Diskussion allerdings vollständig abgeebbt. Das ist vor allem deshalb der Fall, weil die verschiedenen Vor- und Nachteile der möglichen Strategien inzwischen bekannt sind. Es stehen weiterhin sowohl der “Big-Bang Approach”, als auch der “Incremental Approach” im Raum. Während der erste Ansatz in einem einzigen großen Release vollständig auf den neuen Namespace wechseln würde, propagiert Letzterer, die Umstellung nach und nach nur dann durchzuführen, wenn sich an den jeweiligen Spezifikationen auch wirklich Änderungen ergeben. Eigentlich hat wohl jeder damit gerechnet, dass das Jakarta EE Steering oder Specification Committee nun endlich eine Entscheidung treffen. Schließlich wartet die ganze Java-Community gespannt darauf, welche der Strategien für die Umstellung Anwendung findet. Leider gibt es aber nach über drei Monaten immer noch keine klare Aussage darüber, welche Strategie weiter verfolgt wird. Das Thema scheint etwas in den Hintergrund gerückt zu sein.

Trotzdem ist die Jakarta EE Community natürlich nicht untätig. Einer der Gründe für die Verzögerung bei der Entscheidung über die Namespace-Migration ist sicherlich die für September geplante Veröffentlichung von Jakarta EE 8. Der Plan für dieses erste Jakarta EE Release wurde bereits vor vielen Monaten erstellt. So wird Jakarta EE 8 das erste, vollständig nach den Regeln des “Jakarta EE Specification Process” verabschiedete Release und somit die Jungfernfahrt für den neuen Spezifikationsprozess sein. Da die erstmalige Anwendung des neuen Prozesses bereits eine große Herausforderung ist, wird Jakarta EE 8 keinerlei technische Neuerungen enthalten und somit identisch zu Java EE 8 sein. Das bedeutet vor allem, dass dieses Release auch weiterhin den javax-Namespace nutzen wird. Das ist nur deshalb möglich, weil der javax-Namespace auch weiterhin genutzt werden kann, solange er unverändert bleibt. Die Frage der Namespace-Migration spielt für Jakarta EE 8 also gar keine Rolle und wird erst für Jakarta EE 9 relevant.

W-JAX 2019 Java-Dossier für Software-Architekten

Kostenlos: Java-Dossier für Software-Architekten 2019

Auf über 30 Seiten vermitteln Experten praktisches Know-how zu den neuen Valuetypes in Java 12, dem Einsatz von Service Meshes in Microservices-Projekten, der erfolgreichen Einführung von DevOps-Praktiken im Unternehmen und der nachhaltigen JavaScript-Entwicklung mit Angular und dem WebComponents-Standard.

 

Für ein echtes Jakarta EE Release fehlte lange Zeit allerdings eine ganz wichtige Komponente. Zwar sind die APIs der Spezifikationen, sowie die ehemaligen Referenzimplementierungen und das TCK bereits vor längerer Zeit zur Eclipse Foundationen migriert worden, allerdings fehlten bislang die Spezifikationsdokumente, welche einen ganz wesentlichen Aspekt der Plattform darstellen. Vor über einem Monat wurde auf der Mailingliste verkündet, dass die Dokumente inzwischen von Oracle an die Eclipse Foundationen übermittelt wurden und nun nur noch grob vom IP-Team der Foundation geprüft werden, bevor sie in die Git-Repositories der jeweiligen Projekte übertragen werden. Leider ist das bisher nur zu einem sehr kleinen Teil geschehen. Genau genommen wurde bisher lediglich die ehemalige “Java EE Platform Specification” offiziell freigegeben. Diese sogenannte “Umbrella Specification” definiert die Plattform selbst, aus welchen Komponenten sie besteht, globale Aspekte wie das Class-Loading, den Aufbau der Deployment Artefakte und die beiden Profile. Obwohl die Plattformspezifikation natürlich von enormer Bedeutung ist, da sie Jakarta EE aus all seinen Einzelteilen zusammensetzt, stellt sie vom Gesamtumfang her natürlich nur einen sehr kleinen Teil dar. Kurz nachdem die Spezifikation im Git-Repository auftauchte, wurde auch direkt damit begonnen, aus der “Java EE Platform” die “Jakarta EE Platform” zu machen. Das zeigen die inzwischen fast 170 Commits der letzten drei Wochen.

Spezifikationsdokumente

Und was ist mit den anderen Spezifikationen? Das Release von Jakarta EE 8 ist für den 10. September geplant. Da die Jakarta EE Plattform eine Aggregation vieler einzelner Spezifikationen ist, müssen diese jeweils zuvor ein Release veröffentlichen. Die eigentliche Herausforderung ist dabei, dass die verschiedenen Technologien aufeinander aufbauen. Das lässt sich anhand eines konkreten Beispiels am besten verdeutlichen. Jakarta Server Faces beispielsweise hängt von Jakarta CDI ab, welches wiederum die Jakarta Interceptor API verwendet, die aber selbst die Jakarta Annotation API als Abhängigkeit hat. Das heißt, dass die entsprechenden Spezifikationen in einer wohldefinierten Reihenfolge veröffentlicht werden müssen. Zunächst muss also das Jakarta Annotation API ein Release fertigstellen, damit die Jakarta Interceptor API diese neue Version auch nutzen kann. Erst, wenn dies für alle Abhängigkeiten geschehen ist, kann auch die Jakarta Interceptor API veröffentlichen, und so weiter.

Lange Rede, kurzer Sinn. Der Zeitdruck für das geplante Release ist enorm und noch immer stehen die Spezifikationsdokumente, welche eigentlich eine Voraussetzung für das Release sind, nicht zur Verfügung. Der aufmerksame Leser wird vielleicht das Wort “eigentlich” bemerkt haben. Man hat sich nämlich eine Art “Workaround” ausgedacht, damit der Zeitplan noch eingehalten werden kann. Alle Projekte, welche bisher keinen Zugriff auf die Spezifikationsdokumente haben, erstellen sogenannte “Boilerplate Specifications”, welche dann die Basis für Jakarta EE 8 werden. Aber was ist eine Boilerplate Specification? Dabei handelt es sich einfach gesprochen, um das minimale Grundgerüst eines Spezifikationsdokuments, aber ohne den eigentlichen Inhalt. Es gibt also eine Titelseite, ein zunächst fast leeres Inhaltsverzeichnis und Informationen über die Lizenz. Mehr aber auch nicht. Ohne Inhalt ist das Dokument natürlich nicht viel wert. Zumindest eine Referenz auf die entsprechende Java EE Spezifikation aus JCP Zeiten und der Hinweis, dass die Jakarta Spezifikation identisch mit dieser ist, wäre sicherlich sinnvoll. Ob dies bis zum geplanten Release noch geschehen wird, ist allerdings noch nicht klar. Diese “Übergangslösung” ist natürlich nur teilweise zufriedenstellend. Schließlich sollte Jakarta EE 8 ein erstes echtes Release nach den Regeln des Jakarta EE Specification Process werden. Wenn allerdings nur leere Dokumente durch den Prozess laufen, dann ist das natürlich nicht wirklich eine echte Anwendung des Prozesses.

Auch wenn es etwas enttäuschend ist, dass eine solche Übergangslösung für die Dokumente angewendet werden muss und Jakarta EE 8 nach außen hin identisch mit Java EE 8 ist und somit für den Entwickler keinerlei neue Funktionen bringt, so muss man doch anerkennen, dass hinter den Kulissen sehr viele organisatorische Umstrukturierungen stattfinden, die notwendig für die zukünftigen Jakarta EE Versionen sind. So sind beispielsweise inzwischen fast alle Projekte in echte “Eclipse Specification Projects” umstrukturiert worden, für die in einigen Bereichen etwas andere Regeln gelten, als für normale Projekte. Die damit verbunden Aufgaben wie die Namensfindung und die Festlegung eines “Scope Statements” haben ihre Zeit gebraucht, aber dieser einmalige Aufwand ist inzwischen gestemmt.

Jakarta EE TCK & die Akrynome

Ein anderer Bereich, in dem sich aktuell viel bewegt, ist das Jakarta EE TCK. Mit knapp 34.000 Dateien und 4,6 Millionen Codezeilen ist dieses spezielle Projekt organisatorisch natürlich eine besondere Herausforderung. Vor allem, weil das TCK zu einem großen Teil eine Aggregation aus vielen einzelnen TCKs ist, die jeweils die Kompatibilität mit den entsprechenden Einzelspezifikationen prüfen. Schon sehr früh wurde der Ruf laut, dass das TCK doch aufgeteilt werden sollte, so dass der jeweils zu einer Spezifikation gehörende Teil auch von den jeweiligen Committern des Spezifikationsprojekts gepflegt werden kann. Von diesem Schritt ist man allerdings noch weit entfernt. Inzwischen gibt es aber Verfahren, mit denen die Implementierungsprojekte eigene CI-Jobs erstellen können, um den jeweils für sie relevanten Teil des TCKs auszuführen. Dies ist sicherlich ein wichtiger Schritt für die Projekte, da nur durch kontinuierliches Verifizieren der Kompatibilität mit der Spezifikation ein sinnvolles Arbeiten möglich ist.

Bezüglich des TCKs gilt für Jakarta EE 8 auch eine weitere Besonderheit. Im Normalfall soll das TCK ja bekanntlich prüfen, ob eine Implementierung kompatibel mit einer Spezifikation ist. Um den Aufwand für Jakarta EE 8 gering zu halten, ist aktuell allerdings kein neues Release der Implementierungsprojekte geplant. Das ist theoretisch auch nicht unbedingt nötig, weil Jakarta EE 8 und Java EE 8 bezüglich der API identisch sind. Allerdings werden neue Versionen der APIs veröffentlicht. Um sicherzustellen, dass sich in diese neuen Versionen keine Fehler einschleichen, werden die Spezifikationsprojekte dieses mal das TCK selbst ausführen. Dabei wird dann die neue API gegen eine garantiert kompatible Version der Implementierung geprüft. Dieses Verfahren ist zwar ungewöhnlich, macht aber durchaus Sinn. Ob es wirklich dabeibleibt, dass es bei den Implementierungsprojekten keine neuen Versionen geben wird, bleibt allerdings abzuwarten. Zumindest hört man bereits Gerüchte darüber, dass es eventuell nicht dabeibleiben wird.

Ansonsten gibt es noch Neuigkeiten bezüglich der Akronyme. Wie bereits in der letzten Ausgabe ausführlich beschrieben, stand einige Zeit im Raum, dass Jakarta EE die altbekannten Akronyme (wie z.B. JAX-RS, JPA, EJB, etc.) nicht mehr verwenden darf. Wobei schon damals die rechtliche Grundlage Fragen aufgeworfen hat. Inzwischen ist ein Dokument veröffentlicht worden, in welchem genau beschrieben wird, wie mit den Akronymen umzugehen ist. Kurz zusammengefasst gilt die Regel, dass die Akronyme in den Namen der Packages und an einigen wenigen anderen Stellen ausdrücklich erlaubt sind. In allen anderen Fällen soll sehr explizit darauf hingewiesen werden, ob sich ein Akronym auf die Jakarta EE Version, oder aber auf die alte Java EE Spezifikation bezieht. Oracle fürchtet anscheinend, dass der Unterschied zwischen Jakarta EE und Java EE verschwimmt, soltten auch weiterhin die alten Abkürzungen genutzt werden. Auch in der Jakarta EE Community scheint sich inzwischen die Meinung durchzusetzen, dass neue Akronyme oder vielleicht sogar der Verzicht auf Akronyme zu bevorzugen ist, vor allem, um sich von Java EE abzugrenzen. Aus JAX-RS könnte dann Jakarta REST werden und Java Server Faces wird dann vielleicht Jakarta Faces genannt. Aber hier gibt es noch keine finale Entscheidung und aktuell sieht es sogar so aus, als würden die verschiedenen Projekte sogar unterschiedliche Wege gehen wollen.

Wie man also sieht, passiert mal wieder viel in der Jakarta EE Welt. Wenn alles gut geht, erscheint in einem Monat mit Jakarta EE 8 die erste offizielle Version des Java EE Nachfolgers. Man darf also gespannt sein, wie es ab dann weitergeht.

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: