Suche
Zum Stand der Dinge

Java EE & EE4J: Wie geht’s jetzt weiter?

Hartmut Schlosser

© Shutterstock / sociologas

Die Übertragung der Java-EE-Projekte an die Eclipse Foundation ist in vollem Gange. Zum Stand der Dinge und den anstehenden Aufgaben hat sich nun Mike Milinkovich, Direktor der Eclipse Foundation, zu Wort gemeldet. Wie geht’s nun weiter mit EE4J?

Wie erinnern uns: Oracle hatte im September 2017 entschieden, sämtliche Java-EE-Projekte an die Eclipse Foundation zu übertragen – sehr zur Freude der Community. Bedingung dafür war aber, den Namen Java EE sowie das Package javax für neue Technologien nicht mehr zu nutzen, da Oracle die Namensrechte am Brand „Java“ nicht aufgeben möchte.

Adieu Java EE

Seither wurden die Java-EE-Technologien unter das neue Eclipse-Toplevel-Projekt EE4J eingeordnet. Ob EE4J allerdings auch der offizielle Name für das ehemalige Java EE werden soll, ist noch unklar. Wie Milinkovich in seinem Blogpost EE4J: Current Status and What’s Next nun zusammenfasst, ist die Namenssuche noch nicht abgeschlossen. Das Projekt-Management-Committee hat in einem Meeting letzte Woche eine Liste potenzieller Namen ausgegeben, die momentan von der Foundation auf die namensrechtliche Situation hin überprüft wird.

Selbstverständlich müsse ein hoher Grad an Sicherheit gewährleistet werden, so Milinkovich, dass dieser neue Name für eine solch exponierte Technologie wie Java EE auch weltweit problemlos eingesetzt werden dürfe. Sobald diese markenrechtlichen Checks abgeschlossen sein werden, wird die Foundation mit einer Liste an Kandidaten an die Community herantreten und zur finalen Abstimmung aufrufen.

Ein erstes Release

Der zweite Punkt ist die konkrete Übertragung der Quellcodes von den Oracle-geführten Repositories nach EE4J auf GitHub. Die ersten neun EE4J-Projekte sind bereits eingerichtet und provisioniert. Zu definieren ist nun, welche Projekte als nächstes migriert werden sollen. Oracles Vorschlag lautet hier das JSON-B API und JavaMail. Milinkovich will danach die Projekte JAX-B, JAX-WS, JSTL, UEL, JAF, Security, JTA, Enterprise Management, Concurrency und Common Annotations umziehen.

Ziel ist es auf alle Fälle,  die Migration so schnell wie möglich abzuschließen, um die Gründung einer aktiven Community um diese Quellcode-Basen zu befeuern. Außerdem soll bald ein Java-EE-8 kompatibles Release des EE4J-Projektes zur Verfügung gestellt werden. Dies wäre dann eine Java EE 8 zertifizierte Version des Eclipse-Glassfish-Servers samt daran angeschlossener Projekte.

Bis dahin bittet Milinkovich, noch keine Änderungen an den migrierten APIs in EE4J-Projekten vorzunehmen. Es wird derzeit nämlich auch ein neuer Spezifikationsprozess ausgearbeitet, um die Evolution der APIs zu regeln. Hierbei muss wohl vor allem noch die Möglichkeit der Nutzung des javax-Namespaces geklärt werden, an dessen Brandnamen Oracle ja noch festhält. Wer dennoch bereits an neuen API-Prototypen arbeiten möchte, dem empfiehlt Milinkovich den Fork der GitHub-Repositories.

Adieu JCP

Ein letzter Punkt: Wie wird denn nun der Standardisierungsprozess für EE4J aussehen, der an die Stelle des JCP treten soll? Auch hier ist das letzte Wort noch nicht gesprochen. Doch Milinkovich kann bestätigen, dass eine Eclipse Foundation Working Group ein Governance-Modell anstrebt, dass die Mitglieder der EE4J-Community in den Vordergrund stellen soll. Solche Workinggroups begleiten bei Eclipse gewisse Open-Source-Projekte, um Ökosystem-Aspekte wie Marketing, Entwickler-Kommunikation, Branding und Compliance-Programme abzudecken.

Zum geplanten Governance-Modell hatte Milinkovich letzte Woche auf der EE4J-Mailingliste ausgeführt, dass es hier keine Sonderrechte für bestimmte Mitglieder oder Unternehmen geben wird:

The Eclipse Foundation is going to be creating a new specification process which will replace the role of the JCP as it currently pertains to Java EE. That new spec process will hopefully fix many of the issues with the JCP. I can guarantee that it will not have the existing „get all the IP“ Spec Lead role. Similarly I can guarantee that it will not have any special votes or roles for Oracle or any other special company.

Die erste Tat der EE4J-Working-Gruppe wird darin bestehen, eine Governance Charter aufzusetzen. Ein erster Entwurf dieser Charter soll bereits Ende Januar eingesehen werden können.

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.