Kolumne: EE Insights

Jakarta EE 9: Release-Plan und angestrebtes Datum veröffentlicht – so wird die neue Version aussehen

Christian Kaltepoth

Am 10. September 2019 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.

Das neue Jahr hat begonnen. Die Feiertage liegen hinter uns und für die Meisten hat der Alltag inzwischen wieder begonnen. Und so ist es auch für die Jakarta EE Community. Nach der weihnachtlichen Auszeit in den letzten Wochen beginnt nun wieder die Arbeit an dem großen Ziel für das Jahr 2020, nämlich dem Release von Jakarta EE 9.

Wie zuletzt bereits berichtet, hatte Oracle Ende letzten Jahres als erste Partei damit begonnen, die eigenen Pläne und Vorstellungen für Jakarta EE 9 zu formulieren und zur Diskussion zu stellen. Da Oracle allerdings inzwischen keine Sonderstellung mehr bezüglich der Planung von Jakarta EE hat, dienten diese Ideen in erster Linie als Diskussionsgrundlage für die konkreten nächsten Schritte.

Der Big Bang

Verantwortlich für den Jakarta EE 9 Release Plan ist das Jakarta EE Platform Project. Wie der Name bereits andeutet, ist dieses Projekt für die Plattformspezifikation zuständig, welche wiederum zu einem Großteil aus den bekannten Einzelspezifikationen besteht. Für den Release Plan hat das Plattform-Projekt lediglich einige wenige Vorgaben vom Jakarta EE Steering Committee erhalten. Dieses hatte Anfang Dezember 2019 festgelegt, dass Jakarta EE 9 den Big Bang Approach für die Migration vom javax– in den neuen jakarta-Namespace anwenden soll. Außerdem wurde beschlossen, dass die Migration der Paketnamen das zentrale Ziel von Jakarta EE 9 werden soll und es keine neue Funktionalität geben wird. Die einzige Ausnahme davon bilden einige wenige Spezifikationen, welche in Java SE 9 aus dem JDK entfernt wurden und somit zwangsläufig benötigt werden. Dazu aber später mehr.

Auf Grundlage des ersten Entwurfs von Oracle und dem Feedback der Community aus den letzten Wochen hat das Jakarta-EE-Plattform-Projekt den Release Plan erarbeitet und auf der Webseite veröffentlicht. Aktuell wird über den Plan abgestimmt. Obwohl die Abstimmung noch diese Woche läuft, zeichnet sich bereits ab, dass es eine deutliche Mehrheit für die aktuelle Fassung gibt. Man kann also davon ausgehen, dass der Plan im Laufe dieser Woche noch genehmigt wird. Grund genug, einen genaueren Blick darauf zu werfen.

Wie bereits durch das Jakarta EE Steering Committee vorgegeben, beschreibt das Planungsdokument zunächst, dass die Namespace-Migration das Hauptziel für Jakarta EE 9 ist. Alle in Jakarta EE 9 enthaltenen Spezifikationen müssen also vom javax-Package in das neue jakarta-Package wechseln. Darüber hinaus sollten keinerlei Änderungen an den Spezifikationen enthalten sein. Das heißt vor allem, dass es höchst wahrscheinlich keinerlei neue Funktionalität geben wird. Allerdings erwähnt das Dokument auch, dass Ausnahmen möglich sind, allerdings eine explizite Zustimmung benötigen. Jedoch liegt die Vermutung nahe, dass kaum eine Spezifikation von dieser Möglichkeit Gebrauch machen wird.

Da die Umstellung der Paketnamen eine sehr gravierende Änderung bezüglich der Kompatibilität mit früheren Versionen darstellt, müssen alle Spezifikationen eine neue Major-Version veröffentlichen. Jakarta EE 9 wird somit beispielsweise Jakarta Servlet 5.0, Jakarta Persistence 3.0 und Jakarta Server Faces 3.0 enthalten. Über die Sinnhaftigkeit eines erzwungenen Sprungs auf die nächste Major-Version kann man sicherlich streiten. Vor allem, weil es sich nur teilweise um einen „Breaking Change“ handelt. Zwar wechselt der Paketname, was an sich natürlich ein Kompatibilitätsbruch ist, jedoch ändert sich inhaltlich ansonsten nichts an den Spezifikationen, wodurch sich die Migration des eigenen Quellcodes zumindest in vielen Fällen mit einem einfachen „Suchen & Ersetzen“ erledigen lässt.

Zusätzlich wird empfohlen, dass die Spezifikationsdokumente bezüglich des neuen Namensraums angepasst werden. Leider wird dies aber nicht bei allen Dokumenten möglich sein, weil nicht alle Projekte Zugriff auf die Dokumente haben. Das liegt daran, dass bis heute noch nicht alle rechtlichen Voraussetzungen erfüllt sind, um die Spezifikationsdokumente unter dem Dach der Eclipse Foundation weiterzuentwickeln. Der Grund dafür ist, dass alle Autoren, die an den Dokumenten in der Vergangenheit mitgewirkt haben, explizit eine Erlaubnis erteilen müssen, damit rechtlich alles in geordneten Bahnen läuft. Da einige der Dokumente aber über 10 Jahre alt sind, ist diese Aufgabe leider nicht allzu leicht zu erfüllen. Somit steht auch weiterhin die Gefahr im Raum, dass für einzelne Spezifikationen die Dokumente gar nicht freigegeben werden können und somit neugeschrieben werden müssen. Es bleibt allerdings zu hoffen, dass die Eclipse Foundation diesbezüglich bald gute Nachrichten hat.

Bereits im ersten Entwurf von Oracle zum Plan für Jakarta EE 9 war enthalten, dass Abwärtskompatibilität zum alten javax-Namensraum nicht durch die Plattform vorgeschrieben wird. Dies soll vor allem neuen Herstellern von Anwendungsservern den Einstieg erleichtern. Bestehende Anwendungsserver werden aller Voraussicht nach von sich aus irgendeine Art von Abwärtskompatibilität anbieten, die den Betrieb alter Java-EE-Anwendungen erlaubt, um den eigenen Kunden entgegenzukommen.

Die richtige Java-SE-Version vorausgesetzt

Ein weiterer zuvor angesprochener Punkt betrifft die Anforderung an die Java SE Version. Sowohl Java EE 8, als auch Jakarta EE 8 setzten jeweils Java SE 8 voraus. Obwohl Java SE 8 auch heute noch sehr verbreitet ist, so existiert mit Java SE 11 bereits seit geraumer Zeit eine neue LTS-Version von Java SE. Oracle schlug daher im ersten Entwurf des Plans vor, die Mindestvoraussetzung auf Java SE 11 zu erhöhen. Im Release Plan ist es allerdings anders umgesetzt worden. Die Anforderung lautet nun, dass alle Spezifikationen mit dem Source Level 8 kompiliert werden müssen, die Anwendungsserver ihre Kompatibilität allerdings auf Basis von Java SE 11 zertifizieren müssen. In der Praxis dürfte diese Variante ausreichend sein, um den Wunsch vieler Entwickler zu erfüllen: Jakarta EE 9 Anwendungen werden mit Java SE 11 entwickelt werden können, auch wenn die Jakarta EE API selbst lediglich Java SE 8 verwendet.

Bleibt lediglich die Frage, welche Spezifikationen denn nun überhaupt Bestandteil von Jakarta EE 9 werden. Oracle hatte bereits im ersten Entwurf des Plans den Vorschlag gemacht, die Gelegenheit zu nutzen und einige der veralteten Teile der Plattform zu entfernen. Die Idee dahinter ist sicherlich, den Aufwand für die Namespace-Migration so klein wie möglich zu halten. Denn warum sollte man Zeit und Mühe in Spezifikationen investieren, die eh keine Relevanz mehr haben und bereits als „deprecated“ gekennzeichnet wurden. Die Liste der Kandidaten für eine Entfernung wurde in den letzten Wochen intensiv diskutiert. Letztendlich ist die Liste aber kleiner ausgefallen, als ursprünglich von Oracle vorgeschlagen. Das liegt vor allem daran, dass einige Hersteller sich nicht so ganz mit dem Gedanken anfreunden konnten, Spezifikationen zu entfernen, die von den eigenen Kunden noch aktiv genutzt werden. Oracle hatte anfänglich zwar bereits klargestellt, das Produkte natürlich auch weiterhin die entsprechenden Technologien unterstützen können, selbst wenn die Plattform diese nicht mehr vorschreibt, allerdings scheint dieses Argument nicht funktioniert zu haben. Fest steht inzwischen, dass die folgenden Spezifikationen nicht Bestandteil von Jakarta EE 9 sein werden:

  • Jakarta XML Registries
  • Jakarta XML RPC
  • Jakarta Deployment
  • Jakarta Management
  • Support for Distributed Interoperability in the EJB 3.2 Core Specification

Wenn man bedenkt, dass ursprünglich sogar die Unterstützung von SOAP-Webservices als Kandidat für die Entfernung diskutiert wurde, so ist diese doch relative kleine Liste vermutlich problemlos zu verkraften. Darüber hinaus werden zwei weitere Spezifikationen als „optional“ eingestuft:

  • Jakarta Enterprise Beans 2.x API group
  • Jakarta Enterprise Web Services, JSR 109

Wie oben bereits angedeutet, werden aber auch einige neue Spezifikationen in Jakarta EE 9 aufgenommen. Dabei handelt es sich aber ausnahmslos um Technologien, die früher Bestandteil von Java SE waren, allerdings in neueren Versionen nicht mehr enthalten sind. Da Jakarta EE 9 nun auch Java SE 11 anvisiert, in dem diese APIs fehlen, musste hier eine Lösung gefunden werden. Konkret geht es um folgende Spezifikationen:

  • Jakarta Activation
  • Jakarta XML Binding
  • Jakarta XML Web Services
  • Jakarta Web Services Metadata
  • Jakarta SOAP with Attachments

Mit Ausnahme der ersten beiden fragt man sich zu Recht, warum diese überhaupt jemals Bestandteil von Java SE waren. Besonders das Thema “Webservices” fällt ja eigentlich schon in die Kategorie „Enterprise“ und hätte vermutlich von Anfang eher Bestandteil von Java EE sein sollen. Ursprünglich wurde diskutiert, ob einige der fünf Spezifikationen nicht sogar im javax-Namespace verbleiben könnten. Letztendlich hat man sich aber darauf geeinigt der Big-Bang-Strategie treu zu bleiben und somit alle in den jakarta-Namensraum zu verschieben.

Wann ist es soweit mit Jakarta EE 9?

Zum Schluss kommen wir zu einer der spannendsten Fragen. Wie genau sieht der Zeitplan aus? Auch dieser Aspekt wird im Release Plan ausführlich thematisiert. Dabei wird zunächst festgelegt, dass die Spezifikationen in acht Phasen veröffentlicht werden sollen. Das hat vor allem mit den Abhängigkeiten untereinander zu tun. Jakarta Server Faces hängt beispielsweise von Jakarta Expression Language ab, wodurch diese natürlich vorher veröffentlicht werden muss. In den ersten Phasen sind also eher Kernspezifikationen wie Jakarta Servlet, Jakarta Interceptors und Jakarta Expression Language zu finden, während die Plattformspezifikation selbst in der letzten Phasen angesiedelt ist. Im Dokument wird explizit darauf hingewiesen, dass Milestones und Release Candidates gewünscht sind, damit die Spezifikationen aus höheren Phasen möglichst schnell auch ihre Abhängigkeiten aktualisieren können.

Bezüglich des konkreten Zeitplans sieht es wie folgt aus: Mitte Februar, also schon in einem Monat, sollen alle Spezifikationen erste Versionen der APIs bereitstellen, die dann bereits auf den jakarta-Namespace umgestellt wurden. Bis Mitte März sollen die benötigen Anpassungen am Jakarta EE TCK durchgeführt werden. Ab diesem Zeitpunkt wären die Implementierungsprojekte somit in der Lage ebenfalls mit den benötigten Anpassungen aufgrund der neuen Paketnamen zu beginnen. Ein erster Release Candidate der Plattformspezifikation ist dann bis Anfang Mai geplant. Mitte Juni sollen dann die finalen Abstimmungen zum Release gestartet werden, die durch den Jakarta EE Specification Process vorgeschrieben sind. Somit wäre dann im Juli mit dem finalen Release zu rechnen. Dieser Zeitplan ist somit noch etwas ambitionierter, als es der ursprüngliche Plan von Oracle vorgesehen hat. Dieser plante das Release eher für den September 2020.

Insgesamt kann man sagen, dass der Release Plan einen soliden Eindruck macht. Auch wenn einige Themen zuvor sehr kontrovers diskutiert wurden, so hat man sich nun doch auf einen Rahmen für Jakarta EE 9 geeinigt, mit dem wohl alle zufrieden sind. Natürlich ist es etwas enttäuschend, dass Jakarta EE 9 keine wirklichen technischen Neuerungen mitbringt, sondern vollständig auf das Thema der neuen Paketnamen fokussiert ist. Trotzdem ist Jakarta EE 9 natürlich ein sehr wichtiges Release, mit dem sich die Jakarta EE Community von Altlasten und rechtlichen Restriktionen befreit.

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

1
Hinterlasse einen Kommentar

avatar
4000
1 Kommentar Themen
0 Themen Antworten
0 Follower
 
Kommentar, auf das am meisten reagiert wurde
Beliebtestes Kommentar Thema
1 Kommentatoren
Alexander Wagner Letzte Kommentartoren
  Subscribe  
Benachrichtige mich zu:
Alexander Wagner
Gast
Alexander Wagner

Danke für diese ausführliche Zusammenfassung. Schön zu hören, dass es konstruktiv in die Zukunft geht. Und bisweilen kann man sich die Zeit auch mit dem MicroProfile vertreiben, wenn man neue tolle Sachen benötigt. Und wer weiß wann es dann irgendwann zur Wiedervereinigung kommt 🙂