Suche
Take Aways von der Java One

Lagebericht von der JavaOne: Was wir über die Zukunft von Java EE und EE4J wissen

David Heffelfinger

© Shutterstock / XiXinXing

Vor der JavaOne hat sich mit der Entscheidung Oracles, Java EE Open Source zu stellen und der Eclipse Foundation zu übergeben, bereits einiges getan. Der Java-EE-Experte David Heffelfinger fasst für JAXenter seine Eindrücke von der JavaOne und seine Suche nach Antworten rund um das Thema Java EE – pardon EE4J – zusammen .

Die JavaOne 2017 fand letzte Woche in San Francisco statt. Ich hatte wieder einmal das Vergnügen, als Redner auf der Konferenz zu sein und die Bühne mit anderen großartigen Rednern zu teilen, wie David Delabassee, Java EE Evangelist bei Oracle, Ivar Grimstad, JCP Spec Lead und Mitglied des Expertenkomitees, Gaurav Gupta, Autor des exzellenten Jeddict NetBeans Plug-ins, Steve Millidge, Gründer von Payara, und Michael Nascimento Santos von der brasilianischen JUG SouJava.

Ich war auch Teil eines Java-EE-8-Panels, das von Elder Moraes organisiert wurde, der von der SOUJava ist und außerdem Oracle Cloud Evangelist. Zu den Panelteilnehmern zählten Adam Bien, Ed Burns, Ivar Grimstad, Steve Millidge, Reza Rahman, Antoine Sabot-Durand, Bruno Souza, Kevin Sutter, Ruslan Synytsky und Edson Yanaga. Ich habe auch mehrere Sessions von anderen großartigen Rednern auf der Konferenz gesehen – zu viele, um alle zu nennen.

Wie immer war auf der Konferenz zu viel los, um an allen Sessions, Hands-on-Labs, Hackergarten-Aktivitäten und Meetings teilnehmen zu können. Da ich stark in der Java EE Community involviert bin, habe ich versucht, so viele Java EE Sessions und Events zu besuchen, wie ich konnte.

Java EE wandert zu Eclipse

Die große Java-EE-Neuigkeit war der Umzug von Java EE zur Eclipse Foundation. Die Java EE Community befürwortet diese Nachricht im Großen und Ganzen. Da die News noch so frisch ist, sind noch nicht alle Einzelheiten geklärt. Es gibt viele Fragen aus der Java Community. Auch diejenigen, die am Übergang von Java EE von Oracle zur Eclipse Foundation beteiligt sind, haben noch nicht alle Antworten.

Ich habe versucht, einige der häufigsten Bedenken der Community und auch die ersten Antworten der an dem Übergang Beteiligten zusammenzutragen. Bitte beachten Sie, dass keine der Antworten endgültig ist, da noch niemand konkrete Antworten hat, nicht Oracle, nicht die Eclipse-Foundation und nicht die Java-EE-Community-Mitglieder, die am Übergang beteiligt sind. Ich als bescheidener Autor dieser Zeilen habe kein Insiderwissen. Alles, was ich hier schreibe, basiert auf öffentlichen Äußerungen derjenigen, die an dem Übergang beteiligt sind, und der Java EE Community insgesamt.

Lesen Sie auch: Java EE geht an die Eclipse Foundation

Neuer Name für Java EE?

Aufgrund Intellectual-Property-Belange wird Java EE umbenannt, sobald der Umzug zur Eclipse Foundation abgeschlossen ist. Vor kurzem wurde bekannt gegeben, dass Java EE in Eclipse Enterprise for Java umbenannt wird, das neue Akronym für die Technologie ist EE4J. Viele Mitglieder der Java EE Community mögen den Namen nicht. Einige waren verärgert darüber, dass der Name hinter verschlossenen Türen ausgewählt wurde, ohne Input von der Java EE Community. Ein Vertreter von Oracle erklärte, dass die Wahl eines neuen Namens für eine weit verbreitete Technologie wie Java EE kein einfaches Unterfangen sei. Der Name müsse einprägsam sein, er dürfe nirgendwo auf der Welt geschützt sein und er dürfe in keiner Sprache etwas Unangemessenes bedeuten.

Kurz gesagt, Namensfindung ist schwierig. Und einen Namen mit einem Komitee von Tausenden von Entwicklern zu finden, ist ziemlich unmöglich. Mike Milinkovich, Executive Director der Eclipse Foundation, erklärte in einem Blog-Beitrag, dass der Name EE4J der Name des Top-Level-Projekts bei der Eclipse Foundation sei, der eigentliche Technologiename könne in Zukunft anders lauten.

SOUJava-JUG-Leiter und JCP-Mitglied Bruno Souza erklärte, dass der EE4J-Name Sinn ergebe, da der neue Name wegen der Intellectual Property nicht mit dem Wort Java beginnen kann. Außerdem legen die Eclipse-Foundation-Markenrichtlinien fest, dass beim Verweisen auf ein Eclipse-Projekt, das Schema Eclipse[Projektname] gilt, z. B. Eclipse Enterprise für Java. Auch der prominente Java-EE-Experte Adam Bien sprach sich für den neuen Namen aus.

Ich habe an einem EE4J-Panel teilgenommen, bei dem auch das Thema Naming zur Sprache kam. David Blevins, Gründer von Tomitribe, war einer der Panelisten. Obwohl er nicht verriet, ob ihm der Name gefällt oder nicht, erklärte er, dass wir uns nicht so sehr auf den Namen konzentrieren sollten, sondern vielmehr darauf, was wir mit zukünftigen Versionen von Java EE machen können. Er benutzte eine großartige Analogie, um seine Aussage zu illustrieren: „Der Name der Band ist mir egal, mir geht es um die Musik.“

Obwohl ich mit David Blevins darin übereinstimme, dass wir wichtigere Dinge zu tun haben als über den Namen zu diskutieren, habe ich eine Sorge, die ich hier zum Ausdruck bringen möchte. Das „Eclipse“ in „Eclipse Enterprise for Java“ bezieht sich auf die Eclipse Foundation. Viele in der Java Community beziehen sich mit dem Wort Eclipse jedoch auf die Eclipse IDE. Das Wort Eclipse im Namen zu haben, könnte dazu führen, dass einige glauben, dass EE4J nur für Benutzer der Eclipse IDE verfügbar ist. Und das ist definitiv nicht der Fall.

Wie bereits erwähnt, erfordern die Eclipse-Foundation-Richtlinien für die Verwendung von Markennamen, dass dem offiziellen Namen für alle Projekte unter der Leitung von Eclipse der Namen Eclipse vorangestellt wird. Vielleicht wäre es besser, wenn das Wort Eclipse nicht Teil des Akronyms wäre, um diese Situation zu vermeiden. Antoine Sabot-Durand, CDI Spec Lead, schlug vor, den Namen in Eclipse Enterprise Environment for Java umzubenennen. Dies würde das EE4J-Akronym behalten, aber das Wort Eclipse davon entfernen.

Die Namen der Java-EE-API-Pakete

Zurzeit verwenden Paketnamen für Java EE APIs das Java Top-Level Package. Das bedeutet, dass alle Java-EE-bezogenen Klassen und Interfaces in Java-Paketen mit javax beginnen,  z. B. javax.ws.rs für JAX-RS und javax.persistence für JPA. Der aktuelle Plan sieht vor, bestehende Java-EE-Technologien im Namensraum der Java-EE-Pakete zu belassen, aber neue EE4J-Technologien in einen noch festzulegenden neuen Paketnamensraum zu verschieben.

Der javax-Paket-Namensraum impliziert, dass Java EE ein integraler Bestandteil der Java-Sprache ist. Einige prominente Persönlichkeiten in der Java EE Community haben Bedenken geäußert, dass das Verschieben von EE4J-Paketen in einen anderen Paketnamensraum dazu führen könnte, dass einige EE4J nur als ein weiteres Framework wahrnehmen und nicht als integraler Bestandteil von Java. Andere äußerten die Meinung, dass der Plan, bestehende APIs im aktuellen Namensraum zu belassen und neue APIs zu einem neuen Namensraum hinzuzufügen, ein guter Kompromiss sei.

Der Java Community Process von Java EE

Unter der Leitung von Oracle durchlaufen Java-EE-Spezifikationen den Java Community Process (JCP). Es kam die Frage auf, ob der JCP auch nach dem Umzug zur Eclipse Foundation weiterhin genutzt wird. Einige Mitglieder der Java EE Community äußerten sehr lautstark ihren Wunsch, Java EE weiter durch den JCP zu verbessern und zu aktualisieren. Sie erklärten, dass der Prozess in der Vergangenheit gut funktioniert habe. Das Durchlaufen des JCP bedeutet nicht, dass Oracle die Spezifikationen führen muss. Schließlich werden die Bean-Validation- und die CDI-Spezifikation von Red Hat geführt, nicht von Oracle.

Andere Mitglieder der Java Community sind der Meinung, dass sich die Verwaltung von Java EE nach dem Umzug in die Eclipse Foundation vom JCP lösen sollte. Bruno Souza, ein prominenter Vertreter der Java EE-Community und – vielleicht ironischerweise – Mitglied des JCP, erklärte, dass der JCP der beste Mechanismus sei, den wir hätten, damit die Community insgesamt zu dem beitragen könne, was im Wesentlichen eine proprietäre Spezifikationssammlung von Oracle sei. Er erklärte, dass nun, da Java EE vollständig Open Source sei, es keinen Sinn mehr ergebe, den JCP zu nutzen. Er glaubt, dass Java EE in eine andere Organsiationsform überführt werden sollte, vielleicht innerhalb der Eclipse Foundation selbst. Weitere Mitglieder der Community äußerten Bedenken hinsichtlich des Umgangs mit geistigem Eigentum durch den JCP und erklärten, dass die JCP-Regeln Oracle stark bevorzugten.

Lesen Sie auch: Die Zukunft von Java EE sieht rosig aus: Das sagen die Experten

Verliert Oracle das Interesse an Java EE?

Einige in der Java Community sehen die Spende von Java EE an die Eclipse Foundation als Zeichen dafür, dass Oracle das Interesse an Java EE verliert. Soweit ich sagen kann, gibt es zu diesem Thema keine öffentlichen Äußerungen von Oracle. Prominente Mitglieder der Java EE Community haben jedoch erklärt, dass die Beweggründe von Oracle keine Rolle spielen. Was zählt, ist das Endergebnis:  Und Java EE Open Source zu stellen ist ein sehr gutes Ergebnis.

Technologiekompatibilitätskit und Java-EE-Zertifizierung

Unter der Leitung von Oracle müssen Anbieter von Java-EE-konformen Applikationsservern das so genannte Technology Compatibility Kit (TCK) bestehen. Java-EE-Anwendungsanbieter müssen Oracle bezahlen, um Zugriff auf das TCK zu erhalten, damit sie ihre Produkte als Java-EE-kompatibel zertifizieren lassen können. Das TCK ist nicht öffentlich verfügbar. Das hat in der Vergangenheit zu Problemen für Open-Source-Java-EE-Applikationsserver geführt.

Obwohl ich persönlich noch keine offiziellen öffentlichen Äußerungen zur TCK-Verfügbarkeit gehört habe, ist, basierend auf den im Moment laufenden Gesprächen, implizit davon auszugehen, dass das TCK frei verfügbar sein wird, sobald der Umzug zur Eclipse Foundation abgeschlossen ist. Damit können aktuelle Applikationsserver, die das TCK noch nicht bestanden haben, dies tun und die Tür zu neuen Java-EE-Implementierungen öffnen, da die Barriere für ein Java-EE-zertifiziertes Produkt drastisch geringer sein wird.

Koexistenz mit MicroProfile

Die MicroProfile-Initiative wurde vor über einem Jahr von einer Reihe von Java-EE-Anbietern und Java-Anwendergruppen ins Leben gerufen. Die Initiative war eine Reaktion auf den als mangelhaft empfundenen Fortschritte bei der Entwicklung von Java EE 8 unter der Leitung von Oracle. Es war sozusagen eine Möglichkeit für Organisationen außerhalb von Oracle, die Dinge in ihre eigenen Hände zu nehmen und Java EE ohne Oracles Mitwirkung voranzubringen.

Da Java EE nun zur Eclipse Foundation wechselt, haben einige Mitglieder der Java EE Community Bedenken geäußert, dass die MicroProfile-Initiative überflüssig oder obsolet werden könnte. Oracle werde nicht so viel Kontrolle über Java EE haben, wie es der Fall war, als es die Technologie komplett besaß. Zu diesen Bedenken gibt es noch keine definitiven Antworten.

Mark Little von Red Hat sagte, dass die Entscheidung, was mit MicroProfile zu tun sei, von den MicroProfile- und EE4J-Communities selbst getroffen werden müsse. Die Eclipse Foundation würde das Ergebnis nicht diktieren. David Blevins äußerte die Hoffnung, dass die MicroProfile-Initiative fortgesetzt werden kann, indem es ein Unterprojekt von EE4J wird. Dann könnten die neueren Technologien in MicroProfile hinzugefügt und damit experimentiert werden, bevor diese Technologien nach dem Heranreifen zu EE4J wechseln.

Gesellschaftliches Engagement

Während Java EE in die Eclipse Foundation übergeht, wird es sicherlich eine Zeit der Ungewissheit geben. Einige könnten eine Abwarten-und-Tee-trinken-Haltung annehmen und warten, bis die Bewegung erfolgreich ist, bevor sie einen eigenen Beitrag leisten oder Anwendungen für die neuen Spezifikationen entwickeln. Tomitribe-Gründer David Blevins forderte die Java EE Community dazu auf, sich an den Bemühungen zu beteiligen und keine abwartende Haltung einzunehmen. „Wenn jeder abwartet und nichts tut, wird nichts passieren“, sagte er. Ich stimme dieser Meinung ausdrücklich zu und fordere die Java EE Community auf, sich zu beteiligen. Der erste Schritt ist die Aufnahme in die EE4J-Community-Mailingliste, die hier verfügbar ist.

Verwandte Themen:

Geschrieben von
David Heffelfinger
David Heffelfinger
David Heffelfinger ist unabhängiger Consultant, mit einem Fokus auf Java, Java EE und J2EE. Er ist der Autor einiger Bücher über Java und verwandte Technologien, wie z.B. „Java EE 6 Development with NetBeans 7“, „Java EE 6 with GlassFish 3 Application Server“, etc. und arbeitet bereits seit über 20 Jahren in den Bereichen Software Architektur, Design und Development. Java ist bereits seit 1996 seine primäre Programmiersprache. Zudem wurde von David von TechBeacon als einer von 39 Java-Oberhäuptern und –Experten benannt und dazu aufgerufen ihm auf Twitter zu folgen: http://techbeacon.com/java-leaders-you-should-follow-twitter
Kommentare

Schreibe einen Kommentar

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