Kolumne: EE Insights

Noch viele offene Fragen bei Jakarta EE: Von Big Bang und Incremental Approach bis hin zu Spezifikationsnamen und -dokumenten

Christian Kaltepoth

Viel tut sich momentan bei der Java Enterprise Edition: der Umzug nach Eclipse, die Umbenennung in Jakarta EE, der neue Community-getriebene Prozess, die Konsolidierung und Weiterentwicklung der Standards. 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.

Inzwischen ist es fast zwei Monate her, dass Mike Milinkovich, Direktor der Eclipse Foundation, in seinem Blog-Post die schlechte Nachricht mitteilte: Die neuen Jakarta-EE-Versionen der ehemaligen Java-EE-Technologien dürfen nicht mehr im javax-Namespace veröffentlicht werden. Die seit über einem Jahr mit Oracle geführten Verhandlungen waren ergebnislos abgebrochen worden. Der anfängliche Schock hat sich inzwischen bei den meisten gelegt. Das Kind ist also in den Brunnen gefallen, also stellt sich die Frage, wie die Jakarta EE Community mit dieser neuen Situation umgeht.

Big Bang vs. Incremental Approach

Seit mehreren Wochen wird auf den diversen Jakarta-EE-Mailing-Listen nun schon diskutiert, wie eine Migration auf den neuen Namespace konkret ablaufen könnte. Dabei haben sich recht früh zwei alternative Herangehensweisen herauskristallisiert, welche wohl am praktikabelsten sind. Im sogenannten „Big Bang Approach“ würden auf einen Schlag alle Spezifikationen auf den neuen jakarta-Namespace umgeschrieben. Das würde aber frühestens mit Jakarta EE 9 geschehen. Das Ziel für Jakarta EE 8 wurde bereits vor langer Zeit festgesetzt: Jakarta EE 8 soll die erste offizielle Jakarta-EE-Version werden und aus technischer Sicht identisch zu Java EE 8 sein. Nur mit dem wichtigen Unterschied, dass Jakarta EE 8 durch den neuen Spezifikationsprozess ratifiziert wird. Eine Änderung des Namespaces wäre also frühestens mit Jakarta EE 9 möglich.

Als Alternative zum „Big Bang Approach“ gilt der sogenannte „Incremental Approach“. Mit dieser Strategie würden im ersten Schritt nur die Spezifikationen auf den neuen Namespace wechseln, welche sich auch wirklich weiterentwickeln. Dieser Plan würde also ausnutzen, dass es Jakarta EE auch weiterhin erlaubt ist, unveränderte Packages im javax-Namespace zu veröffentlichen. Würde also beispielsweise „Jakarta Server Pages“ keinerlei Änderungen an den Klassen und Interfaces vornehmen, so könnte auch weiterhin der javax-Namespace genutzt werden. Ändert sich aber nur ein Detail des APIs, sodass die Binärkompatibilität nicht mehr gegeben ist, wäre dies nicht mehr möglich und ein Wechsel auf den jakarta-Namespace wäre notwendig.

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.

 

Ursprünglich war geplant, dass die Community bis Anfang Juni Feedback zu den beiden Strategien geben soll. Allerdings sind die Diskussionen auch bis heute noch nicht abgeebbt. Ein klarer Gewinner scheint sich bisher nicht zu zeigen. Und das ist nicht wirklich überraschend. Schließlich haben beide Variante ihre Stärken und Schwächen. Es scheint so, als wären besonders die Entwickler, die in ihrem täglichen Job mit Java/Jakarta EE arbeiten, eher für den „Big Bang Approach“. Dabei wird als Begründung häufig genannt, dass eine einmalige Anpassung der eigenen Anwendungen auf jeden Fall einfacher wäre, als mit jedem zukünftigen Jakarta EE Release nach und nach Namespaces anpassen zu müssen. Letzteres wäre beim „Incremental Approach“ der Fall, wenn eine Spezifikation erst zu einem späteren Zeitpunkt Änderungen umsetzen möchte und somit auch erst später die Migration des Namespaces durchführt. Auf der anderen Seite argumentieren besonders einige der Anbieter von Anwendungsservern, dass der Big Bang Approach besonders bei den nicht mehr so aktiven Spezifikationen viel Arbeit erzeugt, welche eigentlich nicht nötig sei. Bei Technologien wie JCA und EJB wird es aller voraussicht nach in absehbarer Zukunft keine wesentlichen Änderungen geben. JCA ist sehr stabil und EJB wird vermutlich nach und nach durch CDI ersetzt. Daher stellt sich berechtigterweise die Frage, ob ein Umzug auf den neuen Namespace überhaupt lohnt.

Wie genau die Migration auf den neuen Namespace durchgeführt werden soll, ist also noch offen und wird heftig diskutiert. Inzwischen sind Alternativen mit ihren Vor- und Nachteilen bekannt und auch entsprechend dokumentiert, sodass die entsprechenden Jakarta-EE-Gremien eine gute Grundlage für die Abstimmung haben. Dass die Entscheidungsfindung so lange dauert, ist natürlich schade. Die Jakarta EE Community wartet schon lange auf echten spürbaren Fortschritt, der sich nach außen hin nicht richtig zu zeigen scheint. Allerdings darf man auch nicht vergessen, dass hinter den Kulissen hart an Lösungen gearbeitet wird. Viele der ausstehenden Entscheidungen haben sehr weitreichende Konsequenzen für die gesamte Java-Welt, nicht nur auf Jakarta EE. Daher ist es auf jeden Fall von größter Wichtigkeit, dass die Entscheidungen sorgfältig getroffen werden. Trotzdem darf man optimistisch bleiben, dass bald eine finale Entscheidung getroffen wird und es dann endlich weiter gehen kann.

Spezifikationsdokumente

Aber auch in einem andere Bereich gibt es Neuigkeiten. Ein weiterer großer offener Punkt sind die aktuell noch fehlenden Java-EE-Spezifikationsdokumente. Zwar sind die APIs der Spezifikationen und das Java EE TCK schon vor geraumer Zeit zur Eclipse Foundation migriert worden, die Spezifikationsdokumente jedoch stehen noch aus. Der Grund für die Verzögerung ist – wie so oft – rechtlicher Natur. Da die Spezifikationen unter dem Dach des JCP von den jeweiligen Expert Groups entwickelt wurden, haben auch verschiedenste Parteien an der Erstellung der Dokumente mitgewirkt. Somit ist auch für diese Dokumente eine genaue Prüfung notwendig, um die Rechte der damaligen Autoren nicht zu verletzen und Jakarta EE auf rechtlich soliden Boden zu stellen.

Glücklicherweise scheint dieser Prozess auf Seite von Oracle aber inzwischen abgeschlossen zu sein. Im Sitzungsprotokoll des Jakarta EE Steering Committee war Anfang des Monats zu lesen, dass die Dokumente von Oracle an die Eclipse Foundation übertragen wurden. Auf Seite der Eclipse Foundation werden die Dokumente aktuell auch noch einmal grob geprüft und dann für die jeweiligen Spezifikationsprojekte freigegeben. Es ist also damit zu rechnen, dass die Dokumente in den nächsten Tagen in die Git-Repositorys eingepflegt werden. Interessant ist in diesem Kontext vor allem, dass die Dokumente im AsciiDoc-Format an die Eclipse Foundation übergeben wurden. Dazu muss man wissen, dass die Dokumente bisher in diversen, teilweise proprietären Dateiformaten geschrieben wurden. Eine mögliche Konvertierung der Dokumente ins AsciiDoc-Format war in der Jakarta EE Community schon sehr früh angedacht worden. Die Tatsache, dass dieser Schritt bereits von Oracle durchgeführt wurde, ist natürlich sehr erfreulich und spart der Jakarta EE Community diesen doch recht aufwendigen Schritt.

Lesen Sie auch: javax vs. jakarta: Eine Zusammenfassung der Namespace-Problematik von Jakarta EE

Nomen est Omen

Ein weiterer interessanter Punkt betrifft die teilweise bereits begonnene Änderung der Spezifikationsnamen. Aufgrund der gescheiterten Verhandlungen zwischen Oracle und der Eclipse Foundation ist es Jakarta EE bekannterweise nicht mehr erlaubt, die Wortmarke “Java” in den Titeln der Spezifikationen zu verwenden. Ursprünglich war in diesem Kontext seitens der Eclipse Foundation auch immer wieder erwähnt worden, dass die bekannten Akronyme (wie beispielsweise EJB, JAX-RS, JPA, etc.) nicht mehr benutzt werden dürfen. Bezüglich der Akronyme stellt sich die Situation allerdings inzwischen doch anders dar. Oracle scheint zwar zu präferieren, dass Jakarta EE die altbekannten Abkürzungen für die Spezifikationen nicht mehr nutzt, damit der Unterschied zwischen Java EE und Jakarta EE klarer wird, allerdings stellt sich die Frage, inwieweit es dafür eine rechtliche Grundlage gibt. Selbst wenn beispielsweise das „Java Persistence API“ in „Jakarta Persistence API“ umbenannt werden würde, so wäre das Akronym schließlich immer noch „JPA“. Solange Oracle den Begriff JPA nicht als Wortmarke registriert hat, spricht aus rechtlicher Sicht vielleicht nichts gegen die weitere Nutzung. Der zukünftige Umgang bezüglich der Akronyme ist auf jeden Fall noch nicht abschließend geklärt und wird im Jakarta EE Steering Committee diskutiert. Spannend ist diese Diskussion vor allem, weil Oracle eine deutlich andere Meinung zu diesem Thema zu haben scheint, als die übrigens Mitglieder des Gremiums. Die Frage ist also, wie die Rechtslage hier genau einzuschätzen ist.

Man kann also zusammenfassen, dass es auch weiterhin viele offene Fragen gibt, die erst geklärt werden müssen, bevor es richtig weiter gehen kann. Die wichtigste der Fragen ist sicherlich, wie genau die Migration auf den neuen Namespace vonstattengehen soll. Dieser Punkt ist vor allem deshalb so wichtig, weil er eine so große Auswirkung auf die gesamte Java Community hat. Daher darf man gespannt sein, wann eine finale Entscheidung getroffen wird und wie diese aussieht.

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: