Kolumne: EE Insights

Jakarta EE 9: Konkrete Pläne in Sicht

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.

Das Release von Jakarta EE 8 am 10. September dieses Jahres war sicherlich der größte Meilenstein, den die Jakarta EE Community bisher gestemmt hat. Die Vorbereitungen haben mehrere Monate gedauert und zwischenzeitlich war gar nicht so klar, ob das geplante Datum für das Release noch zu schaffen ist. Glücklicherweise hat es dann doch geklappt und die erste offizielle Version von Jakarta EE ist pünktlich zum angekündigten Termin veröffentlicht worden.

Obwohl die Eclipse Foundation und die Jakarta EE Community zu Recht stolz auf diese Leistung sein können, so war das Release aus technischer Sicht doch nicht besonders spannend. Jakarta EE 8 entspricht bezüglich dieses Gesichtspunktes exakt Java EE 8 und enthält somit keinerlei neue Funktionalität. Aus organisatorischer und rechtlicher Sicht sieht die Sache natürlich anders aus. Jakarta EE hat eine neue Lizenz, ist im Vergleich zu seinem Vorgänger vollkommen anders organisiert und wurde durch den neuen Spezifikationsprozess standardisiert. Auch wenn diese Punkte natürlich für die Zukunft der Plattform extrem wichtig sind, haben Java-Entwickler in der Praxis erst einmal nichts davon, wodurch sich ein Umstieg in den meisten Fällen auch nicht wirklich lohnen würde.

Jakarta EE 9 – Konkrete Pläne in Sicht?

Daher ist es sicherlich an der Zeit, nach vorne zu blicken. Knapp 7 Wochen nach dem Jakarta EE 8 Release stellt sich vor allem die Frage, wie die konkreten Pläne für Jakarta EE 9 aussehen. Schließlich hat die Eclipse Foundation immer wieder betont, dass Jakarta EE sowohl agiler, als auch schneller in Bezug auf Releases sein will, als es Java EE im Rahmen des JCPs war. Die Uhr tickt also und die Java-Welt wartet gespannt auf die nächsten Schritte.

Interessanterweise hat sich als erstes Oracle formell mit konkreten Vorschlägen für die Roadmap von Jakarta EE 9 geäußert. Das war für viele doch eher überraschend. Schon lange bevor Oracle verkündet hat, Java EE unter dem Dach einer Open-Source-Organisation weiterentwickeln zu wollen, machte bereits das Gerücht die Runde, dass Oracle das Interesse an Java EE verloren hätte. Und der Transfer zur Eclipse Foundation passt in gewisser Weise zu dieser Theorie. Es wäre nicht das erste Mal, dass sich ein Konzern einer Technologie entledigt hat, indem er sie der Open Source Community vor die Füße geworfen hat. Wenn Oracle jetzt allerdings als erste Partei vorgeprescht und konkrete Pläne für Jakarta EE 9 vorstellt, so könnte das durchaus ein Zeichen dafür sein, dass Oracle auch langfristig an der Weiterentwicklung der Plattform mitwirken möchte.

Wie kam es dazu? Am 1. Oktober tauche eine E-Mail mit dem Title „Oracle’s position on Jakarta EE 9“ auf der jakartaee-platform-dev Mailing-Liste auf. Die dort aufgeführten Punkte wurden in den darauffolgenden zwei Wochen intensiv von der Community diskutiert. Auf konkrete Vorschläge und eine Diskussionsgrundlage hatte man schließlich lange gewartet. Das zeigen vor allem die fast 50 Nachrichten im entsprechenden E-Mail-Thread. Zwei Wochen später veröffentlichte Oracle eine leicht angepasste Version des ursprünglichen Plans, in der vor allem in einigen Aspekten das Feedback der Community eingearbeitet wurde. In der entsprechenden E-Mail erwähnte Oracle auch, dass dieser neue Plan dem Jakarta-EE-Plattform-Projekt zur Abstimmung vorgelegt werden würde. Ob dies bereits geschehen ist, lässt sich leider nicht sagen, weil das Plattform-Projekt keine Meeting Minutes veröffentlicht. Da in den Plan aber bereits das Feedback aus der Community eingearbeitet wurde, darf man vermuten, dass er in zumindest recht ähnlicher Form auch vom Projekt verabschiedet werden könnte. Grund genug, einen genaueren Blick auf den konkreten Inhalt zu werfen.

Oracles Plan für Jakarta EE 9

Bereits der erste Punkt geht ans Eingemachte. Unter der Überschrift „Pruning“ wird eine nicht gerade kleine Liste von Spezifikationen aufgeführt, die aus Sicht von Oracle aus der Plattform entfernt werden sollten. In dieser Liste tauchen viele Exoten wie beispielsweise Jakarta XML Registries, RMI-IIOP, Jakarta Web Service Metadata und Jakarta Enterprise Bean interoperability auf, bei denen selbst erfahrene Entwickler vermutlich nicht immer genau wissen, was sich dahinter verbirgt. Aber auch bekanntere Spezifikationen wie Jakarta Enterprise Bean entity beans und CORBA sind aufgeführt. Oracle stellt im Dokument explizit klar, dass die genannten Spezifikationen damit nicht automatisch aus allen Produkten verschwinden werden. Der Plan sieht lediglich vor, Unterstützung dieser nicht mehr durch die Plattformspezifikation zu erzwingen. Natürlich steht es aber jedem Anbieter eines Applikationsservers vollkommen frei, mehr Spezifikationen zu unterstützen, als das Mindestmaß vorgibt. Und es ist sogar zu erwarten, dass kaum jemand den Support für bestimmte Technologien aus seinem Produkt entfernt, wenn diese bereits unterstützt werden. Besonders, weil die eigenen Kunden potenziell noch darauf angewiesen sind. Neuen Anwendungsservern hingegen wäre es aber erlaubt, auf diese Spezifikationen zu verzichten und sich trotzdem als Jakarta-EE-Implementierung zu bezeichnen.

Auf der Liste der Spezifikationen taucht allerdings auch ein Kandidat auf, der auf der Mailing-Liste zu heftigen Diskussionen geführt hat. Und zwar schlägt Oracle auch Jakarta XML Web Services für die Entfernung in Jakarta EE 9 vor. Würde diese Spezifikation aus der Plattform verschwinden, würde Jakarta EE somit von Haus aus keine Unterstützung für SOAP-Webservices mehr beinhalten. Zugegebenermaßen hat SOAP seine Hochzeit schon hinter sich und die Verwendung dieser Art von Webservice-Technologie wird bei neuen Projekten bei nahezu Null liegen. Trotzdem trifft man in Bestandssystemen auch heute noch häufig SOAP-Services an, sodass sich einige Mitglieder der Jakarta EE Community mit der Entfernung schwertun. Trotzdem sei an dieser Stelle noch einmal darauf hingewiesen, dass Anwendungsserver natürlich auch zukünftig SOAP-Support anbieten dürfen, wenn es denn gewünscht ist. Daher könnte auf die Unterstützung von SOAP in der Plattform eventuell wirklich verzichtet werden. Trotzdem scheint das Thema SOAP die Community aktuell noch zu spalten, sodass dieser Vorschlag sicherlich im Plattform-Projekt noch intensiv diskutiert werden muss, bevor eine Entscheidung gefällt werden kann.

Big Bang ante portas

Im zweiten Punkt aus Oracles Vorschlag geht es um eines der wichtigsten noch ausstehenden Themen für Jakarta EE, nämlich die Migration der Packages vom javax– in den jakarta-Namespace. In diesem Punkt betont Oracle kurz und knapp, dass der „Big Bang Approach“ empfohlen wird, laut dem im nächsten Jakarta EE Release auf einen Schlag sämtliche Spezifikationen in den neuen Namensraum wechseln würden. Interessant ist diese Aussage vor allem deshalb, weil sich bisher eher die Community für diese Strategie ausgesprochen hat. Vor allem die Hersteller hatten in der Vergangenheit oft die Vorteile des „Incremental Approach“ hervorgehoben. Wobei es allerdings häufig so wirkte, als ging es lediglich darum, den Aufwand auf Seite der Hersteller möglichst gering zu halten. Zumindest für Endanwender kann es sicherlich nur von Vorteil sein, wenn das Thema Namespace-Migration in einem Rutsch angegangen wird und somit in der Zukunft nicht mehr auf die Tagesordnung zurückkehrt.

In diesem Kontext stellt Oracle auch klar, dass es für alle Hersteller unbedingt nötig sein wird, Abwärtskompatibilität in Bezug auf den neuen Package-Namespace zu gewährleisten. In der Praxis würde das bedeuten, dass Jakarta-EE-9-Anwendungsserver zwar primär den jakarta-Namespace verwenden, aber auch das Deployment älterer Anwendungen unterstützen würden, welche noch die javax-Packages nutzen. Gerade das Thema Abwärtskompatibilität war für Java EE schon immer von zentraler Bedeutung und das wird sich auch in der Jakarta-EE-Welt nicht ändern. Auch wenn also eine Abwärtskompatibilität in Bezug auf die Namespace-Migration eine besondere Herausforderung darstellt, sollte es dennoch im Interesse aller sein, eine gute Lösung zu finden. Oracle schlägt diesbezüglich vor, gemeinsam an einer konkreten Strategie zu arbeiten, was idealerweise in einem eigenen Open-Source-Projekt stattfinden könnte, an dem sich alle Hersteller beteiligen. Ideen für Lösungen gibt es bereits genug. So wurden beispielsweise ClassLoader-basierte Ansätze vorgeschlagen, bei denen die Package-Namen transparent übersetzt werden könnten. Denkbar wäre dies sicherlich, vor allem, weil Java EE schon immer spezielle Regeln für die Sichtbarkeit von Klassen in Deployment-Artefakten definiert hat und somit kein Server ohne recht flexible ClassLoader-Hierarchien auskommt.

Nichts Neues?

Der Vorschlag zur Entfernung einiger Spezifikationen aus der Plattform und der Vorstellung einer Strategie für die Namespace-Migration wird natürlich bei Entwicklern nicht gerade Begeisterungsstürme auslösen. Schon Jakarta EE 8 war ja bekanntlich funktional identisch zu Java EE 8 und brachte damit in der Praxis keinen nennenswerten Mehrwert. Leider ist der Abschnitt „Enhancements“ in Oracles Plan für Jakarta EE 9 auch sehr kurz gehalten. Hier wird lediglich erwähnt, dass neue Features in der nächsten Version durchaus denkbar wären, allerdings nur unter der Bedingung, dass diese den Zeitplan nicht negativ beeinflussen. Hier macht Oracle klar, dass der Fokus bei Jakarta EE 9 eindeutig nicht darauf liegt, neue Features zu liefern, sondern eher darauf, die Namespace-Problematik zu lösen. Trotzdem besteht noch Hoffnung, dass Jakarta EE 9 doch das ein oder andere neue Feature erhält. Das JAX-RS-Team beispielsweise ist nicht mehr weit von einem neuen Release entfernt, welches mit dem Java SE Bootstrapping API auch eine große Neuerung bringt. Wenn dieses Release zeitnah möglich ist, spricht vermutlich nichts dagegen, diese neue Version der JAX-RS-Spezifikation auch in Jakarta EE 9 aufzunehmen.

Ein weiterer Punkt aus dem Vorschlag Oracles betrifft die Java-SE-Version für Jakarta EE 9. Sowohl Java EE 8 als auch Jakarta EE 8 basierten noch auf Java 8. Inzwischen ist aber Java 11 die aktuelle LTS-Version und das Release von Java 14 ist auch nicht mehr weit entfernt. Oracle schlägt daher vor, dass Jakarta EE 9 mindestens Java 11 voraussetzen sollte. Vermutlich wird dieser Vorschlag breite Unterstützung erhalten, da die meisten Entwickler die Neuerungen in aktuellen Java-Versionen sehr zu schätzen wissen. Gleichzeitig stellt Oracle aber auch klar, dass die Nutzung von Java 11 nicht bedeutet, dass die Plattform auch gleichzeitig das neue Java-Modulsystem verwenden muss. Dies sollte definitiv ein langfristiges Ziel sein, allerdings handelt es sich hier auch um eine alles andere als einfache Aufgabe, welche sicherlich ihre Zeit benötigt. Trotzdem wäre das Update auf Java 11 sicherlich zu empfehlen, auch wenn das Thema Modularisierung erst später angegangen wird.

TCKs & Ausblick

Auch bei den letzten beiden Punkten aus dem Vorschlag gibt Oracle eher einen Ausblick auf die Zeit nach Jakarta EE 9. Zum einen wird die Beziehung zum MicroProfile-Projekt thematisiert. Oracle glaubt, dass auch die Microprofile-Community den Eclipse Foundation Specification Process (EFSP) nutzen sollte und die Teilprojekte dann gute Kandidaten für die Aufnahme in die Jakarta-EE-Plattform wären. Dies sei aber nicht das Ziel für Jakarta EE 9, sondern eher für die langfristige Planung. In diesem Zusammenhang wäre es sicherlich interessant zu erfahren, wie die MicroProfile-Community zu dieser Idee steht. Konkrete Äußerungen gab es bisher jedoch noch nicht.

Der letzte Punkt betrifft die zukünftige Organisation des TCKs, welches aktuell in einem einzigen großen Git-Repository von einem separaten Projektteam gepflegt wird. Oracle unterstützt den Plan, das TCK aufzuteilen, sodass die Spezifikationsprojekte den jeweiligen Teil des TCKs selber pflegen können. Diese Idee wurde ja bereits vor über einem Jahr geäußert und in großer Mehrheit befürwortet, da sich dadurch die Arbeit am TCK besser organisieren lässt. Allerdings muss auch in diesem Fall klar sein, dass die Aufteilung des TCKs eine nichttriviale Aufgabe ist. Immerhin besteht das Jakarta EE TCK aus knapp 34.000 Dateien und über 5 Millionen Codezeilen. Daher plädiert Oracle auch in diesem Fall dafür, die vollständige Aufteilung nicht für das Jakarta EE 9 Release einzuplanen, sondern stattdessen mit einem inkrementellen Ansatz zu arbeiten, der aber auch schon zeitnah begonnen werden könnte.

Somit bleibt lediglich eine der spannendsten Fragen noch offen. Für wann ist das Release von Jakarta EE 9 geplant? Für diesen Punkt schlägt Oracle vor, maximal 12 Monate ab dem Release von Jakarta EE 8 anzustreben. Das würde also bedeuten, dass Jakarta EE 9 spätestens im September 2020 das Licht der Welt erblicken würde. Das ist natürlich ein recht großer Zeitraum, besonders wenn man betrachtet, dass die Community seit Java EE 8 keinerlei technische Neuerungen mehr gesehen hat. Allerdings ist der Plan auch realistisch, da vor allem die Namespace-Migration ein sehr großer Aufwand ist. Gerade deshalb denke ich, dass es definitiv das Ziel sein sollte, auch das eine oder andere neue Feature für Jakarta EE 9 einzuplanen. Ob das wirklich realistisch ist, bleibt abzuwarten. Trotzdem ist es natürlich ein gutes Zeichen, dass endlich ein konkreter Plan existiert und die Jakarta EE Community ein konkretes Ziel vor Augen hat.

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: