Geschnitten oder am Stück?

Big Bang oder inkrementell: Die Zukunft von Jakarta EE liegt in den Händen der Community

Dominik Mohilo

© Shutterstock / christitzeimaging.com

Noch bis Sonntag, 9. Juni 2019, kann die Community die Diskussion über den richtigen Umgang mit der Namespace-Problematik im Zusammenhang mit Jakarta EE führen. Prominent sind dabei aktuell zwei Lösungen: Entweder der Big Bang oder ein Schritt-für-Schritt-Ansatz. In diesem Beitrag haben wir noch einmal alle derzeit relevanten Informationen zusammengetragen.

Mittlerweile jeder, der sich für Java EE, bzw. Enterprise / Cloud-natives Java interessiert, sollte mittlerweile mitbekommen haben, dass Oracle die Enterprise-Edition an die Eclipse Fondation überstellt hat. Damit einher gingen allerdings nicht die Namensrechte, weshalb die Community einen neuen Namen – Jakarta EE – bestimmt hat, unter dem die Spezifikationssammlung nun weiterentwickelt wird.

Der Umzug von Oracle zur Eclipse Foundation sollte sich mittlerweile in den letzten Zügen befinden, laut dem letzten offiziellen Update von Mike Milinkovich, Executive Director der Eclipse Foundation. In einem jüngst veröffentlichten Blogbeitrag wurde von Mike auch der Plan noch einmal bestätigt, Jakarta EE 8, das von den Features her identisch mit Java EE 8 sein wird, im Herbst dieses Jahres zu veröffentlichen.

Jakarta EE 9, Jakarta EE 10 und die javax-Geschichte

Da es nicht so ganze einfach ist, in Bezug auf die aktuellen Entwicklungen rund um Jakarta EE auf dem Laufenden zu bleiben, hat Tanja Obradovic, Jakarta EE Program Manager, einen monatlichen Newsletter angekündigt, in dem sie die wichtigsten Neuigkeiten zusammenfassen wird. Auf der JAX 2019 hatten wir Gelegenheit, mit ihr über den Status Quo von Jakarta EE und die Namespace-Problematik zu sprechen (siehe Video).

Zusammenfassend ist zu javax zu sagen, dass dieser Namespace nicht mehr weiterentwickelt werden darf. Im Umkehrschluss heißt das, dass jede Spezifikation, die aktualisiert oder verändert wird, die genutzten Package-Namen von javax oder java in jakarta umbenennen muss.

Doch wie soll das Ganze vonstattengehen? Dazu gibt es aktuell eine große Diskussion auf der Mailing-Liste jakartaee-platform-dev. Bis zum 9. Juni 2019 kann die Community dort die beiden Hauptvorschläge diskutieren, oder neue Ideen und Ansätze einbringen, wie man die Namespace-Frage beantworten sollte.

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.

 

Big Bang vs. inkrementell

Bislang haben sich zwei Ideen dazu durchgesetzt, der sogenannte Big Bang und ein Schritt-für-Schritt-Ansatz (zusammengefasst von David Blevins, Tomitribe). Der Big Bang sähe vor, sämtliche Packages in Jakarta EE 9 auf einmal von javax auf jakarta umzustellen. EE 9 wäre dann ebenfalls identisch zu Jakarta EE 8 (und damit zu Java EE 8), mit der Ausnahme der geänderten Namespaces. Ab Jakarta EE 10 könnten dann endlich neue Features und wichtige Aktualisierungen der bestehenden Spezifikationen stattfinden.

Beim Schritt-für-Schritt-Ansatz würde den Vorteil bringen, sofort mit Innovationen beginnen zu können. Die Namespaces sich ändernder APIs würden dann peu à peu auf jakarta umgestellt, wenn Bedarf dazu besteht. Der Nachteil wäre logischerweise, dass der eingeschränkte alte Namespace weiterhin in Gebrauch wäre. Außerdem wäre Jakarta EE 9 ein Mix aus verschiedenen Namespaces und Jakarta EE 10 ein anderer Mix aus Namespaces.

BJ Hargrave, Senior Technical Staff Member bei IBM hat auf seinem Blog einen Beitrag veröffentlicht, in dem er sich explizit für eine inkrementelle Herangehensweise ausspricht. Eines seiner Argumente ist, dass es Spezifikationen gibt, die mit dem javax-Namespace wunderbar und stabil laufen und vermutlich ohnehin nicht mehr geändert werden müsste. Somit habe es keinen technischen Wert, dies übers Knie zu brechen.

Weniger dramatisch sieht den Bruch Rudy De Busscher, Senior Java Entwickler, Java-EE-Experte & Mitglied der Java EE Guardians, wie er auf der Mailing-Liste anmerkt:

What is true, is the fact that the Big Bang has no technical value. But with an incremental approach, developers will need to adapt their application with each release of Jakarta EE. Because a few specs will be changed in Jakarta EE 9, a few more in Jakarta EE 10, and so on.

Auch Adam Bien konnten wir auf der diesjährigen JAX zu dem Thema befragen. Für ihn ist die ganze Affäre rund um den Namespace nicht so dramatisch, wie er auch auf seinem Blog bereits erwähnte.

Ausblick

Wie die Diskussion auf der Mailing-Liste zeigt, gibt es derzeit noch große Uneinigkeit, welches Vorangehen das richtige wäre. Es gibt für beide Ansätze gute Argumente. Es wird seitens der Eclipse Foundation und der Projektleitung schwierig werden, das sieht man bereits jetzt, alle Mitglieder glücklich zu machen – wenn nicht gar unmöglich.

Damit die Entscheidungsfindung sich möglichst einfach gestaltet, wäre es von eminentem Vorteil, wenn alle, die sich für Jakarta EE (bzw. Enterprise Java im Allgemeinen) an der Diskussion beteiligen würden. Dies geht, wie gesagt, über die entsprechende Mailing-Liste und noch bis zum 9. Juni.

Die beiden Proposals und einige weiterführende Hintergrundinformationen, die bei der Meinungsbildung behilflich sein sollten, sind von David Blevins im Startbeitrag zusammengefasst. Alles Wesentliche zum Hintergrund, warum javax ausgedient hat, gibt es im Blog-Beitrag von Mike Milinkovich und hier auf JAXenter.

javax – Die gute und die schlechte Nachricht für Enterprise Java

Verwandte Themen:

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: