Erste Diskussionen zu Jakarta EE 9

Jakarta EE 9: Die Zeichen stehen auf Big Bang

Dominik Mohilo

© Shutterstock / jirawat phueksriphan

Jakarta EE 8 ist veröffentlicht und damit ist die Enterprise Edition von Java nun endgültig zur Eclipse Foundation umgezogen. Nach einem tiefen Durchatmen beginnen nun langsam die Diskussionen zur Zukunft des Projektes. Bill Shannon, Architect bei Oracle, hat einen ersten Entwurf für Jakarta EE 9 vorgelegt, der nun heftig diskutiert wird.

Die Liebe von Oracle zu Java EE kann, bedenkt man die letzten zwei bis drei Jahre der Enterprise Edition von Java, durchaus vom geneigten Leser in Frage gestellt werden. Wer allerdings behauptet, dass Oracle kein Verantwortungsbewusstsein bezüglich der Java-Version zeige, der wird – einmal mehr – eines Besseren belehrt. Niemand geringeres als Oracle Architect Bill Shannon hat nämlich das erste Proposal für das erste „echte“ Release von Jakarta EE (Version 9) vorgelegt.

Jakarta EE 9 wird das erste „Feature Release“ unter dem Dach der Eclipse Foundation sein, allerdings bereits das zweite Release überhaupt. Version 8 von Jakarta EE erschien in einer mit Java EE 8 identischen Ausführung und ist als abschließender Meilenstein des Umzugs von Oracle zur Eclipse Foundation anzusehen.

Jakarta EE 9 – Der Vorschlag von Oracle

Bill Shannons Proposed Plan für Jakarta EE 9 kann nicht als offizieller Oracle-Plan verstanden werden. Es ist einfach Zufall, dass ein engagiertes Community-Mitglied der Java-EE-Gemeinde von Oracle ist und sich – natürlich – auch mit seinen Kollegen in seinem Unternehmen über den möglichen nächsten Schritt für das Enterprise-Java-Projekt unterhalten hat. Aus diesen Überlegungen und Gedanken entstand ein Statement von Oracle, das schließlich nach einigen Kommentaren noch einmal überarbeitet und in seiner jetzigen Form als offizieller Vorschlag für und von der Community als Diskussionsgrundlage anerkannt wurde.

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.

 

Aufräumarbeiten

Der erste Teil des Plans für Jakarta EE 9 betrifft das Entfernen einiger Spezifikationen aus Jakarta EE 9:

  • Jakarta XML Registries
  • Jakarta XML RPC
  • Jakarta Deployment
  • Jakarta Management
  • Jakarta Enterprise Bean entity beans
  • Jakarta Enterprise Bean interoperability
  • Jakarta Enterprise Bean 2.x and 1.x client view
  • Jakarta Enterprise Web Services

Diese sollen dennoch weiterhin bei der Eclipse Foundation vorliegen, allerdings keine Updates mehr erhalten. Natürlich soll es für die Implementierungsprojekte weiterhin möglich sein, Service-Updates zu fahren, immerhin gibt es noch einige Nutzer der Specs, allerdings sollen diese dann nicht von der offiziellen Plattformspezifikation definiert werden. Steve Millidge von Payara schlägt unterdessen vor, Jakarta Management erst einmal optional bereitzustellen und später auszubauen.

Hinzu kommen einige APIs, die eng mit Java SE 8 zusammenhängen, die nicht implementiert werden sollen:

  • Jakarta XML Web Services
  • Jakarta SOAP Attachments
  • Jakarta Web Service Metadata
  • CORBA and RMI-IIOP

Anders als diese, schlägt Bill Shannon vor Jakarta XML Binding und Jakarta Activation in der kommenden Version der Enterprise Edition zu implementieren.

Der Big Bang

Seit Oracle klargestellt hatte, dass der Namespace javax.* für Jakarta EE nur unter Einhaltung des Status Quo der Spezifikationen zur Verfügung stehe, ist klar, dass die Packages umbenannt werden müssen. Unklar ist bis dato aber, ob man nur die Specs auf den neuen Namespace umziehen möchte, die auch wirklich geändert werden, und damit quasi einen peu-a-peu-Ansatz verfolgen will, oder ob man gleich alle Spezifikationen umzieht.

Letzteres ist als sogenannter Big-Bang-Ansatz in die Diskussion eingegangen und scheint das Herz der meisten Entwickler und Mitglieder der Community erobert zu haben. Bill Shannon schlägt in seinem Proposal vor, sämtliche (nach den Aufräumarbeiten verbliebene) Specs direkt und ohne Umschweife auf den jakarta.* Namespace umzuziehen. Der Vorteil: Nach einmaliger Anstrengung und einmaligem Bruch der Rückwärtskompatibilität kann die Weiterentwicklung von Jakarta EE beginnen, ohne bei jedem Release die Namespace-Frage neu aufzugreifen.

Die Frage nach der Rückwärtskompatibilität von bestehenden Projekten soll dabei jedenfalls nicht in der Jakarta-EE-Spezifikation angesiedelt sein. Stattdessen sollen die Produkte, die auf Java EE bzw. Jakarta EE basieren, selbst dafür sorgen. Möglicherweise wird auch ein eigenes Open-Source-Projekt hierfür ins Leben gerufen.

Java SE, TCKs, Microservices & Container

Logischerweise sollte Jakarta EE 9 auch die Java SE unterstützen. Vorgesehen ist als Mindestversion das aktuellste Long Term Release Java 11. Auch die Java-Module sollen berücksichtigt werden, Regeln und Guidelines für Specs, die Module definieren, sollen entwickelt werden. Die Jakarta-EE-9-Plattform selbst soll allerdings nicht modularisiert werden. Allerdings sollen Microservices besser unterstützt werden, das gilt auch für den Einsatz ohne Container.

Ein Wunsch, der sehr viel Arbeit nach sich ziehen wird, ist die Aufteilung des TCK-Projektes. Ziel dieser Idee ist es, allen Projekten der Jakarta-EE-Plattform zu ermöglichen, ein eigenes TCK zu verwalten. Dies wird aber für Jakarta EE 9 eher nicht in Betracht gezogen. Zum einen wegen dem oben erwähnten Arbeitsaufwand und zum anderen, weil sichergestellt werden muss, dass eine solche Änderung das Testen von Jakarta-EE-Produkten nicht zusätzlich erschwert.

MicroProfile + Jakarta EE = Enterprise Java von Morgen?

Seit unserer Reihe Klartext Jakarta EE ist ein wenig Zeit vergangen. Damals hatten die meisten auf die Frage, ob MicroProfile in das Projekt Jakarta EE übergehen soll, mit „nein“ geantwortet. MicroProfile solle ein eigenständiges Projekt bleiben, so das Gros der Teilnehmer, in dem innovative Ideen und Konzepte ausprobiert werden können. Sozusagen ein kleiner Inkubator für das große Standardwerk Jakarta EE.

Im Proposal von Bill Shannon wird nun ein anderer Ton angeschlagen: MicroProfile APIs sollen durchaus in die Jakarta-EE-Plattform implementiert werden, die Arbeit des Projektes unter dem Schirm des Jakarta EE Specification Process gestellt werden. Allerdings soll dies nicht für Jakarta EE 9 umgesetzt werden. Dieser Weg wird nicht gerade einfach, sollte er denn beschritten werden, daher räumt man sich hierfür mehr Zeit ein.

Ausblick auf Jakarta EE 9 und weiter

Wie man sowohl im Vorschlag von Bill Shannon als auch u.a. in den Antworten von Red Hat und Payara sieht, sollen die bestehenden APIs und Specs nicht überarbeitet werden. Der Grund hierfür ist die Namespace-Problematik: Wenn man schon umzieht, dann sollten nicht noch die umzuziehenden Assets überarbeitet werden – dafür ist später noch Zeit.

Die Zeichen stehen also auf „Big Bang“ und sogar zum Erscheinungsdatum hat man sich bereits geäußert: Offenbar wurde sich darauf eingeschossen, Jakarta EE 9 maximal 12 Monate nach Jakarta EE 8 fertigzustellen. Das würde bedeuten, dass im Herbst 2020 eventuell eine Version von Jakarta EE zu erwarten ist, die als Basis für die Weiterentwicklung der Plattform und der einzelnen Spezifikationen dienen kann – das klingt erst einmal positiv.

Andererseits sind 12 Monate auch eine lange Zeit und man wird sehen, wie sich der Markt in den kommenden Wochen entwickeln wird. Die Arbeit, Jakarta EE zum definitiven Platz für Cloud-natives Java zu machen, wird jedenfalls nicht abreißen.

Das aktuelle Proposal von Bill Shannon, ebenso wie die gesamte Diskussion dazu, finden sich auf der Mailing-Liste jakartaee-platform-dev, die für jeden Interessierten frei einsehbar ist. Wer sich beteiligen möchte, der kann sich einfach dort anmelden.

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

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: