Kommentar: Eine Chance für Jakarta EE

Mike Milinkovichs Blog-Beitrag zum gegenwärtigen Stand der Verhandlungen zwischen der Eclipse Foundation und Oracle zur Verwendung von Oracles Markenrechten im Eclipse-Projekt Jakarta EE hat viele Insider ernüchtert und Java-Nutzer verunsichert. Das Ergebnis der Auseinandersetzung zwischen beiden Parteien ist nun, dass die Jakarta-EE-Community den Namensraum des javax-Pakets nicht nutzen kann. Auch Java-Marken wie die bestehenden Spezifikationsnamen dürfen von Jakarta-EE-Spezifikationen nicht verwendet werden.

Ein Kommentar von Alexander Neumann

Alexander Neumann ist Leitender Redakteur von heise Developer, das er von Beginn an betreut hat, und organisiert darüber hinaus mehrere erfolgreiche Entwicklerveranstaltungen.

Sicherlich wäre es besser, bestehende APIs in den javax-Paketen ohne Einschränkungen weiter nutzen zu können. Letztlich wird die Enterprise-Java-Szene aber mit der jetzigen Situation leben müssen. Sowohl Eclipse Foundation als auch Oracle haben das Mögliche versucht und nun an der richtigen Stelle einen Beschluss gefasst – hoffentlich im Sinne einer guten und gesicherten Zukunft von Jakarta EE. Kein US-amerikanisches Unternehmen, zumal mit riesigen Rechtsabteilungen wie Oracle, wird solche Rechte wie die bislang verhandelten abtreten. Und keine gemeinnützige Stiftung wie die Eclipse Foundation wird ihre Existenz durch eine solche Auseinandersetzung aufs Spiel setzen.

Alles klar, nichts gut?

Das Gute an der jetzigen Situation ist womöglich, dass das Thema, das zu einem großen Teil dazu geführt hat, dass man hinter den ursprünglichen Fahrplänen zurückliegt, nun geklärt ist. Vielmehr ist es nun wichtig, genau zu prüfen, wie man im Sinne einer für nahezu alle Parteien, vor allem aber für die Java-Entwickler besten Lösung kommt. Kein leichtes Unterfangen: Gilt es doch, die Kompatibilität mit Jakarta EE 8 für zukünftige Versionen zu gewähren, ohne eine Innovation zu beeinträchtigen.

Denkbar ist zum Beispiel, sich komplett vom javax-Namensraum zu verabschieden und nur noch mit Jakarta-Paketnamen zu arbeiten. Der Nachteil ist hier die mangelnde Rückwärtskompatibilität zu den vielen bestehenden Java-EE-Anwendungen. Die Lösung dieses Problems könnte ein optional aufrufbares Abwärtskompatibilitäts-Profile im Rahmen von Jakarta EE sein, das die APIs von Java EE 8 umfasst, die dann künftige Versionen von Jakarta EE bei Bedarf aufrufen können. Hier wären die Anbieter von Anwendungsservern wie IBM, Red Hat, Payara, Tomitribe und natürlich Oracle selbst gefragt, so ein Profile zu unterstützen. Initial bräuchte es dafür zwei Implementierungen, eine für javax, die es bei Java EE 8 ja schon gibt, und eine jakarta-Implementierung, in der als Fork die notwendigen Änderungen erfolgen würden.

Außerdem vorstellbar ist die Sourcecode-Generierung zum Deploy-Zeitpunkt oder zur Build-Zeit mittels Bytecode-Erstellung oder -Manipulation. Hier könnten spezielle Tools oder Build-Plug-ins helfen, die anfallenden Aufgaben zu meistern. Auf Sourcecode-Ebene könnten die Hersteller der wichtigsten IDEs, insbesondere Eclipse, NetBeans und IntelliJ IDEA, mit ihren Skills beim Refactoring von Code helfen. Das Know-how und die Erfahrungen, Code zu migrieren, sind also durchaus vorhanden.

Innovation dürfte fortan nur noch mit dem Namensraum jakarta geschehen. Gewisse Anwendungen würden demnach vielleicht anfangs komplett auf javax aufbauen, doch dann – bedingt durch Neuerungen und bei Veränderungen an den APIs – zunehmend um jakarta-Pakete ergänzt oder ausgetauscht werden, sodass sich zunehmend das Verhältnis Richtung Jakarta EE verschiebt. Wichtig ist sicherlich, dass allen Entwicklern der Sachverhalt bei den unterschiedlichen Paketnamen vertraut sein müsste und man verwandte Communitys wie Eclipse MicroProfile mit ins Boot holt. Gerade Letztere müsste ein Interesse haben, bei der Gestaltung mitzureden, will sie nicht zur Konkurrenzplattform werden.

Sich von alten Zöpfen trennen

Wo viele erst mal Unsicherheit oder gar ein Ende von Java EE/Jakarta EE sehen, besteht doch eine Chance. Die Situation bietet die Gelegenheit, sich von alten Zöpfen zu verabschieden, von denen man sich schon bald ohnehin lösen hätte müssen, um gegen Mitstreiter aus dem eigenen Lager wie Spring (Boot) oder andere Programmierplattformen (JavaScript, .NET oder Python) bestehen zu können. Tatsächlich ist die Java-Community groß und vielschichtig genug und die zur Verfügung stehenden Werkzeuge sind gereift, um sich auf das neue Abenteuer einzulassen. Eines, das das Versprechen einer Cloud-nativen Zukunft mit Java einlösen kann, ohne auf bewährte Prinzipien der Java-Enwicklung wie Stabilität, Reife und Zuverlässigkeit zu verzichten.

Siehe dazu auf heise Developer:

• Kommentar: Java EE ist tot!
  
• Jakarta EE: Der Anfang vom Ende oder die Chance für einen Neuanfang?
• Oracle will Java EE an die Open-Source-Community übertragen
• Analyse: Oracle scheint bei Java EE im letzten Moment die Kurve zu kriegen
  
• Jakarta EE: Eclipse Foundation übernimmt die Verantwortung für Enterprise Java
• Jakarta EE: Goodbye JCP, willkommen EFSP!
• Jakarta EE: Eine Frage des guten Namens

(ane)