Das ewige Lied vom Copyright

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

Dominik Mohilo

© Shutterstock / christitzeimaging.com

Die Verlautbarung, dass das Projekt Jakarta EE in Zukunft den Namespace javax nicht mehr wird weiterentwickeln dürfen, könnte ein Fanal für die Zukunft von Enterprise Java sein. Die Community von Jakarta EE steht nun vor der Herausforderung, einen neuen Namespace zu etablieren, ohne die Rückwärtskompatibilität zu gefährden.

Lasst uns ehrlich sein: Wirklich überraschend ist die Nachricht, dass der Namespace javax in Zukunft nicht mehr weiterentwickelt werden darf, nicht. Die Intention und den Wunsch beider Seiten – Oracles und der Eclipse Foundation – muss man hoch anerkennen, doch bereits der Zwang, einen neuen Namen für Java EE finden zu müssen, ließ zumindest erahnen, dass die Frage nach dem Namespace zumindest problematisch sein würde.

Nun also ist offiziell die (einvernehmliche) Entscheidung getroffen worden, dass die Eclipse Foundation keinerlei Rechte besitzen wird, Java-Markennamen, deren Urheberrecht bei Oracle liegen, zu verwenden. Damit ist allerdings nicht nur die Restriktion gemeint, den Namespace javax in irgendeiner Weise zu verändern oder zu modifizieren. Es könnte passieren, dass Spezifikationen einzelner Jakarta-EE-Komponenten, die den besagten Namespace nutzen, aus zukünftigen Jakarta-EE-Plattformspezifikationen herausgelassen werden.

Und nicht nur das: Die Eclipse Foundation steht auch vor der Aufgabe, beliebte Projekte namenstechnisch anzupassen, um nicht mehr die „Namenskonventionen“ von Java EE abzubilden – das gilt auch für Akronyme. Konkret: EJB, JPA und JAX-RS steht auch ein Wandel ins Haus.

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.

 

Wie geht es mit Jakarta EE und javax weiter?

Die Antwort auf obige Frage ist nicht einfach, doch es gibt bereits von sehr prominenten Vertretern der Community Ideen und Vorschläge, wie das Problem aus der Welt geschafft werden könnte. Manch einer sieht darin sogar eine vorteilhafte Situation, da man sich nach Abschluss der javax-Evolution komplett und frei irgendwelcher zukünftiger Copyright-Probleme auf die Weiterentwicklung der Jakarta-EE-Plattform stürzen kann.

While this is not what was envisioned when Jakarta EE started, in many ways this in our best interest as the modification of javax would always have involved long-term legal and trademark restrictions.

Mark Little

Der Vorteil dieser erst einmal vielleicht negativ anmutenden Entwicklung liegt, so etwa auch Adam Bien, vor allem in der Möglichkeit, ein konsistentes „Look and Feel and Branding“ bereitzustellen. Dies soll durch die Umbenennung des Namespaces in jakarta geschehen. Adam Bien betonte in seinem Blog-Posting, dass es durchaus akzeptabel sei, einen solchen Breaking Change nach 20 Jahren zu forcieren.

Big Bang Jakarta EE 9

Über den Weg, den es nun zu beschreiten gilt, gibt es kaum eine Diskussion, wohl aber, wie genau er aussehen soll. Eine populäre Variante, die auch Dmitry Kornilov von Oracle favorisiert, ist der sogenannte „Big Bang“. Dies würde bedeuten, auf einen Schlag sämtliche Jakarta EE APIs in ihrem Ist-Zustand auf den neuen Namespace umzuziehen. Optional könnten in diesem Zusammenhang alle Packages, die nicht auf den neuen Namespace umziehen, in Jakarta EE implementiert werden. Einziger Haken: Sie dürften hinterher nicht mehr angefasst werden oder jemals in den neuen Namespace umgezogen werden.

Alternativ dazu könnte man auch eine peu-à-peu-Strategie fahren, von der vor allem die aktivieren Projekte profitieren würden. Der Nachteil davon wäre allerdings eine inkonsistente Ansammlung von APIs, die entweder auf dem neuen oder dem alten Namespace liegen. Anders als bei einem „Big Bang“, der nach dem finalen Umzug und dem Release von Jakarta EE 8 dann für Jakarta EE 9 in Frage käme, könnte man dort dann auch nicht sofort das nächste Feature-Release (Jakarta EE 10) in Angriff nehmen.

Wie genau sich Enterprise Java unter dem Dach der Eclipse Foundation entwickeln und welche Strategie zum Handling der Namespace-Problematik zum Einsatz kommen wird, entscheidet die Community. Daher lohnt es sich, sich an den aktuell laufenden Diskussionen auf den Mailing-Listen zu beteiligen. Die Geschichte rund um den Namespace ist sicher auf den ersten Blick ein negatives Ereignis und nicht das, was man sich erhofft hatte. Dennoch kann dieser „gewaltsam“ herbeigeführte Schnitt als Chance verstanden werden – je nach Gemütslage.

Weitere Informationen zum aktuellen Geschehen gibt es in Mike Milinkovichs Blog-Artikel.

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: