Kolumne: EE Insights

Aus Java EE wird Jakarta EE: Warum, wann – und ist das eigentlich gut?

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.

EE Insights: Aus Java EE wird Jakarta EE…

Aus Java EE wird Jakarta EE. Von dieser Änderung hat sicherlich jeder inzwischen etwas gehört. Trotzdem werden immer wieder dieselben Fragen gestellt: Wie ist es dazu gekommen? Was ändert sich für mich als Nutzer? Warum ein neuer Name? Ist das alles überhaupt eine positive Entwicklung?

Christian Kaltepoth

Um diese Fragen beantworten zu können, muss man sich die Geschichte von Java EE und besonders die Entwicklungen der letzten Jahre genauer anschauen.

Java EE: The story so far

Java EE hat eine sehr lange Geschichte. Schließlich ist die erste Version schon vor fast 20 Jahren von Sun Microsystems veröffentlicht worden. Zum Vergleich: Das war in einer Zeit, in der auf den meisten Desktop PCs noch Windows 98 installiert war. Damals nannte sich Java EE noch J2EE – eine längst überholte Bezeichnung, die man leider bis heute nicht aus den Köpfen der Menschen bekommen hat.

Bis inklusive J2EE 1.4 war die Entwicklung mit der Plattform doch recht schwerfällig. Für ein EJB musste man neben der eigentlichen Implementierung noch mindestens zwei Interfaces und einen gigantischen XML-Deskriptor schreiben, mit dem man das Transaktionsverhalten und viele weitere Aspekte genau definieren musste. Für die Persistenz der Daten sah J2EE Entity Beans vor, eine Technologie, die in der Praxis mehr Probleme verursacht als gelöst hat. Damit die Entwicklung mit J2EE zumindest halbwegs effizient war, ließ man sich einen Großteil der Artefakte mit XDoclet generieren und verwendete lieber Hibernate statt den EJB Entity Beans.

Mit Java EE 5 kam dann die Wende. Sun erkannte, dass eine dramatische Vereinfachung des Entwicklungsmodells unabdingbar war und setze dies mit Java EE 5 um. EJBs konnten nun mit Annotationen definiert werden, Hibernate wurde standarisiert und in Form von JPA das neue Persistenzframework von Java EE. Der Trend der ständigen Vereinfachung wurde auch in den folgenden Versionen stets weiterverfolgt, so dass die Arbeit mit Java EE anfing, richtig Spaß zu machen.

Java EE 6 und Java EE 7 waren ein voller Erfolg, und die Plattform wurde bei den Entwicklern immer beliebter.

Kurz vor der Fertigstellung von Java EE 6 kaufte Oracle im Jahr 2010 Sun Microsystems und übernahm die Weiterentwicklung. Glücklicherweise setzte Oracle die gute Arbeit von Sun in den folgenden Jahren fort, so dass sowohl Java EE 6, als auch Java EE 7 ein voller Erfolg war und die Plattform bei den Entwicklern immer beliebter wurde.

Doch dann kam alles anders…

Der Bruch kam dann Anfang 2016. Die Arbeiten an Java EE 8 waren in vollem Gange. Man hatte sich viel vorgenommen. Java EE sollte endlich bessere Unterstützung für die Cloud bringen und in vielen weiteren Bereichen ausgebaut werden. Mit MVC 1.0 sollte ein neues Webframework Einzug in Java EE erhalten, die Servlet-Spezifikation plante volle Unterstützung von HTTP 2.0, und JAX-RS hatte Themen wie beispielsweise Non-Blocking I/O auf der Agenda. Doch dann kam alles anders.

Kurz nach der JavaOne 2015 stelle Oracle ohne irgendeine Begründung fast sämtliche Arbeiten an Java EE 8 komplett ein. Das äußerte sich vor allem darin, dass es keinerlei Aktivitäten auf den entsprechenden Mailinglisten mehr gab. Von Commits in den Repositories ganz zu schweigen. Es herrschte vollkommener Stillstand. Jegliche Versuche, die Gründe dafür in Erfahrung zu bringen, blieben ohne Erfolg. Vor allem die Community hat in dieser Zeit versucht, die Arbeiten an Java EE 8 trotz alledem fortzusetzen, was aber leider nur sehr einschränkt möglich war. Das lag vor allem an der Art, in der die Java-EE-Spezifikationen im Java Community Process (JCP) erarbeitet wurden.

Zwar existierte zu jeder Spezifikation eine Expertengruppe, die in der Regel aus Mitgliedern verschiedener Firmen und Organisationen bestand, jedoch stellte Oracle in fast allen Fällen den so genannten „Specification Lead“. Im JCP hat der Specification Lead eine zentrale Funktion, während die anderen Mitglieder der Expertengruppe eher eine beratende Rolle haben. Der Specification Lead hat in allen Belangen das letzte Wort, und die Rechte an der Spezifikation liegen alleine bei ihm. In vielen Fällen hatten die meisten Mitglieder noch nicht einmal Schreibrechte für das Source Code Repository, was eine aktive Arbeit an den Spezifikationen ohne die Hilfe Oracles komplett blockierte.

Natürlich gab es diverse Reaktionen auf die Inaktivität von Oracle. So haben sich Anfang 2016 beispielsweise die Java EE Guardians gegründet. Diese hauptsächlich aus Mitgliedern der Community bestehende Gruppe setzte sich zum Ziel, für Java EE und die aktive Weiterentwicklung einzustehen und Oracle dazu zu bewegen, die Arbeit fortzusetzen. Fast zum selben Zeitpunkt wurde auch die MicroProfile-Initiative gebildet. Neben dem spezifischen Fokus auf Microservices war einer der Treiber für die Gründung sicherlich auch, dass die Weiterentwicklung von Java EE stockte und somit nach Alternativen gesucht wurde.

Java EE unabhängig?

Schon damals wurden die Rufe immer lauter, dass Java EE doch besser unabhängig von Oracle weiterentwickelt werden sollte. Aber ein „Fork“ von Java EE war zu diesem Zeitpunkt nicht mehr als Träumerei, da eine solche Abspaltung aus rechtlicher Sicht unmöglich war. Zu groß doch schien die Gefahr, dass es zu einer ähnlichen Auseinandersetzung kommen könnte, wie zwischen Oracle und Google bezüglich der Java APIs in Android.

Ein offizielles Statement zur Zukunft von Java EE gab es von Oracle erst ein Jahr später auf der JavaOne 2016. Oracle betonte, dass Java EE auch weiterhin ein wesentlicher Bestandteil der eigenen Strategie sei und legte auch direkt einen konkreten Plan für die Zukunft vor. Die ursprünglich geplanten Features von Java EE 8 wurden deutlich zusammengestrichen, um die Arbeiten daran noch 2017 abschließen zu können. Gleichzeitig sollten aber bereits die Arbeiten an Java EE 9 beginnen, welches einen starken Fokus auf die Themen Reactive und Cloud legen sollte. Keine Aussage gab es zu den Gründen für die Untätigkeit des letzten Jahres.

Kurz nach der JavaOne nahm Oracle also, nach knapp einem Jahr der Stille, die Arbeit an Java EE 8 wieder auf. Langsam aber stetig bewegte man sich in den Folgemonaten auf das geplante Release zu. Die Begeisterung der Community war durch die Ereignisse der letzten Monate und die zusammengeschrumpfte Roadmap etwas getrübt, aber trotzdem war man natürlich froh, dass es überhaupt weiterging.

Kurz vor dem geplanten Release kam dann die große Nachricht. David Delabassee verkündete die Pläne Oracles, sowohl die Java-EE-Spezifikationen als auch die Referenzimplementierungen unter dem Dach einer Open-Source-Foundation weiterentwickeln zu wollen. Dieser Schritt war für alle sicherlich sehr überraschend. Natürlich träumte man schon lange insgeheim davon, Java EE unabhängig von einem einzelnen Konzern weiterentwickeln zu können. Aber irgendwie hat wohl niemand wirklich daran geglaubt, dass Oracle Java EE tatsächlich freigeben würde.

Java EE bei der Eclipse Foundation

Schnell begannen daraufhin die Diskussionen, welche Open-Source-Foundation denn am ehesten geeignet wäre. Die Beziehung zwischen der Apache Software Foundation und Sun bzw. Oracle waren ja schon immer etwas schwierig. Daher wurden schnell auch die Eclipse Foundation und die Linux Foundation als potentielle Kandidaten genannt. Den Zuschlag erhielt schließlich die Eclipse Foundation, die das neue Zuhause von Java EE werden sollte.

Zusammen mit dieser Ankündigung wurden noch weitere Details bekannt gegeben. Java EE sollte unter eine neue Lizenz gestellt und mit einem flexibleren Spezifikationsprozess weiterentwickelt werden. Leider deutete sich zu diesem Zeitpunkt auch an, dass Java EE einen neuen Namen bekommen musste. Trotz der vielen guten Nachrichten war die Tatsache, dass der Name Java EE nicht weiterverwendet werden konnte, ein Schock für die Community. Nicht alle konnten sich mit dieser Tatsache anfreunden, obwohl schnell klar wurde, dass Oracle diesbezüglich nicht mit sich verhandeln lassen wollte.

Also begann die Suche nach einem neuen Namen. Doch die Hürden waren hoch. So durfte das Wort „Java“ beispielsweise nicht im Namen vorkommen und der Name nicht mit anderen existierenden Trademarks kollidieren. Es wurden hunderte von Vorschlägen eingereicht, von denen der Großteil den harten Anforderungen nicht genügten. Lediglich zwei Namen blieben übrig: Im Februar 2018 konnte die Community zwischen „Jakarta EE“ und „Enterprise Profile“ wählen.

Aus Java EE wird Jakarta EE

Wie wir heute alle wissen, hat „Jakarta EE“ das Finale gewonnen. Aus meiner Sicht ist Jakarta EE eine sehr gute Wahl. Die Verbindung zum ehemaligen Apache-Jakarta-Projekt, unter dessen Dach vor fast 20 Jahren die ersten Java Open-Source-Bibliotheken bei der Apache Software Foundation entwickelt wurden, betont sehr treffend, dass die Community und der Open-Source-Gedanke für Jakarta EE einen hohen Stellenwert haben.

Nachdem die Namensfrage geklärt war, konnte die Migration von Java EE zur Eclipse Foundation endlich beginnen. Seit dem Frühjahr dieses Jahres werden nach und nach diverse Spezifikationen und Referenzimplementierungen in der Form von „Project Proposals“ als Unterprojekte des Eclipse-EE4J-Projektes vorgeschlagen. Diese neuen Projekte durchlaufen eine Reihe von Phasen, bis sie schließlich den Status eines vollständigen Eclipse-Projektes erhalten. Aktuell sind es 39 Projekte, von denen knapp die Hälfte den Prozess der Migration bereits vollständig durchlaufen hat. Das nächste Paket von Projekten steht für die Proposal-Phase bereits in den Startlöchern. Der Prozess ist also noch in vollem Gange, und es gibt viel zu tun.

Die Zukunft

Und wie geht es nun weiter? Aktuell wird hart daran gearbeitet, alle verbleibenden Projekt zur Eclipse Foundation umzuziehen. Gegen Ende des Jahres soll dann Eclipse Glassfish 5.1 erscheinen, ein vollständiger Applikationsserver mit Java-EE-8-Zertifizierung. Im nächsten Jahr ist das Release von Jakarta EE 8 geplant, welches bezüglich des Funktionsumfangs identisch zu Java EE 8 sein soll, allerdings nach den neuen Jakarta-EE-Regeln spezifiziert wurde. Sobald der Spezifikationsprozess vollständig definiert wurde, stehen weiteren Jakarta-EE-Versionen nichts mehr im Wege.

Java EE war und ist von zentraler Bedeutung für unzählige Unternehmen.

Damit sind die meisten der anfänglich gestellten Fragen beantwortet. Nur, ob das alles überhaupt eine positive Entwicklung ist, wäre noch zu klären. Aus meiner Sicht kann man die Frage ganz klar mit „Ja“ beantworten. Java EE war und ist von zentraler Bedeutung für unzählige Unternehmen. In den vergangenen Jahren hat Java EE gezeigt, dass die Zeiten von J2EE vorbei sind und moderne Java-EE-Versionen eine stabile und zukunftssichere Plattform für Unternehmensanwendungen sind.

Allerdings hat sich auch gezeigt, dass die Abhängigkeit von einem einzelnen großen Konzern durchaus Risiken birgt. Die Weiterentwicklung unter dem Dach einer Open-Source-Foundation ist somit ein guter Schritt, um sicherzustellen, dass die Plattform auch in vielen Jahren noch durch eine aktive Community weiterentwickelt und gepflegt wird.

Es gibt also allen Grund, positiv in die Zukunft zu blicken!

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
400
  Subscribe  
Benachrichtige mich zu: