Kolumne

Enterprise Tales: Java EE 8 – ein politisches Release

Lars Röwekamp

Wir schreiben den 21. September 2017. Nach langem, sehr langem Warten gibt Oracle endlich die offizielle Verfügbarkeit des aktuellen Major-Releases Nummer 8 des Java Enterprise Standards bekannt. Ursprünglich angetreten als Cloud- und Microservices-Lösung, ist am Ende kaum mehr als ein Maintenance-Release des Vorgängers herausgekommen. Und trotzdem könnte gerade dieses Release ein Wegweiser für die Zukunft sein.

Über die technischen Neuerungen von Java EE 8 ist bereits mehr als genug geschrieben worden. Daher an dieser Stelle nur ein kurzer Abriss der wichtigsten Ausrichtungen. Nachdem klar wurde, dass die ursprüngliche Ausrichtungen Cloud und Co. zunächst erst einmal „out of Scope“ sein würden, hat sich die Java EE 8 Expert Group stattdessen zum Ziel gesetzt, den Fokus von Java EE 7 – „Modern Web“ – auch im neuen Release weiter zu verfolgen. HTTP/2-Support inkl. Push statt Pull, eine verbesserte Unterstützung von JSON sowie ein Reactive Programming Model stehen ganz oben auf der Liste. Und auch das bereits in Java EE 5 eigeführte Motto „Ease of Development“ wurde weiter ausgerollt. Die Einführung neuer Annotationen in nahezu jedem API sowie ein verbesserter CDI-Support zur vereinfachten Programmierung sind hierfür ein klares Indiz. Zusätzlich findet bei etlichen Java-EE-APIs eine Adaption hin zu den neuen Features von Java 8, wie zum Beispiel die Nutzung von Lambdas oder des Stream-API, statt. Details zu den konkreten Neuerungen und Änderungen innerhalb der verschiedenen APIs enthält der Onlineartikel „Java EE 8: Hält es, was die lange Wartezeit versprochen hat?“.

Politik v1.0

So weit, so gut. Oder auch nicht. Denn nach mehr als vier Jahren Wartezeit hätte der eine oder andere Java-EE-Entwickler sicherlich mit mehr gerechnet – mit deutlich mehr. Eigentlich fing ja auch alles ganz gut an. Nach den Querelen zwischen Oracle und der Community rund um Java EE 7 gelobten beide Seiten Besserung. Es wurde sich gemeinsam an einen Tisch gesetzt und ausgiebig über mögliche zukünftige Ausrichtungen von Java EE diskutiert.

Eine zweiteilige Umfrage unter ca. 5 000 interessierten Mitgliedern der Community sollte die Topthemen der Zukunft herauskristallisieren. Das Ergebnis der Umfrage fiel eindeutig aus: Schlagwörter wie „leichtgewichtig“ und „einfach zu verwenden“ standen ganz oben auf der Wunschliste. Cloud und Co. sowie neue UI-Technologien schienen dagegen eher von geringerem Interesse zu sein. API-Kandidaten, wie JSON-Binding, Java EE Configuration oder jCache bekamen einen Zuspruch von 60 bis 80 Prozent. Gleiches galt für die Fokussierung auf ein Alignement der Verwendung von CDI innerhalb der vielen, vielen existierenden Java-EE-APIs. Vorschläge zu Cloud-nahen Themen dagegen lagen nur selten über 50 Prozent. Die zukünftige Roadmap von Java EE schien somit klar zu sein. Die Expert Group hätte also umgehend loslegen können. Aber leider passierte dann erst einmal eine ganze Zeit lang gar nichts. Oracle konzentrierte sich voll und ganz auf seine Cloud-Strategie. Für Java im Allgemeinen und Java EE im Speziellen schien niemand wirklich Zeit zu haben.

Nicht wenige sind damals davon ausgegangen, dass dies den Anfang von Ende einläute, so u. a. auch die Gründer der „The Java EE Guardians“, eine Initiative zur Rettung von Java EE. Es bedurfte erst einer Menge scharfer Kritik aus der Community und des Weggangs etlicher Java-EE-Experten von Oracle, bevor 2016 eine Kehrtwende eintrat. Ausrichtung und Inhalte von Java EE 8 wurden neu definiert und im Rahmen der letzten JavaOne vorgestellt. Das Ergebnis kennen wir alle in Form des aktuellen Java-EE-Releases. Revolutionäre Neuerungen sucht man allerdings vergebens. Gleiches gilt für Zeitgeistthemen wie Cloud und Microservices.

Politik v2.0

Trotzdem gibt das aktuelle Release Grund zu einer gewissen, wenn auch zunächst vorsichtigen Euphorie. Denn bereits Ende August, also einen Monat vor der offiziellen Veröffentlichung, erklärte Oracle, mit dem Gedanken zu spielen, die Java Enterprise Edition der Open-Source-Community zu übergeben. Nach der eher blockierenden Haltung der letzten Jahre war das eine echte Überraschung. Mittlerweile ist auch bekannt, in welche Open-Source-Organisation Java EE übergehen wird. Von den zwei ernstzunehmenden Kandidaten – Apache Software Foundation und Eclipse Foundation – hat die Eclipse Foundation den Zuschlag erhalten.

Laut David Delabassée, Oracle Software Evangelist, setzt Oracle bei der Transition von Java EE hin zu Open Source stark auf die Mithilfe von IBM und Red Hat. Das liegt nahe, verkörpern die beiden Unternehmen doch schon lange wesentliche Treiber innerhalb der Java-EE-Community. Sowohl IBM als auch Red Hat haben auch bereits ihre Zusage zu einer Kooperation gegeben. Wie genau diese aussehen wird, soll gemeinsam erarbeitet werden. Für diese Art der konstruktiven Zusammenarbeit spricht Delabassée den beiden Mitstreitern explizit seinen Dank aus: „Thank you IBM and Red Hat!“
Im offiziellen Oracle-Java-EE-Blog gibt Delabassée darüber hinaus zu, dass dies nicht unbedingt das gewohnte Vorgehen von Oracle sei: „First, we have reached out to IBM and Red Hat, the other largest contributors to the Java EE platform, to solicit their support for this new direction. Oracle, IBM, and Red Hat are collaborating on an ongoing basis to refine an approach that we can collectively support. This is not the way Oracle used to do things.“

Lesen Sie auch: Java EE 8 ist da! Das sind die wichtigsten Änderungen und Features

Dass es Oracle wirklich ernst zu meinen scheint, lässt sich nicht nur an Worten, sondern vor allem auch an Taten messen. So findet sich beispielsweise der komplette Sourcecode von Java EE mittlerweile auf GitHub. Und auch ein neuer Name ist bereits gefunden. Das war notwendig, da Oracle den bisherigen Markennamen nicht freigeben wollte. Nach etlichen Spekulationen und Gerüchten wurde EE4J (Eclipse Enterprise for Java) offiziell als neuer Name kommuniziert. Ein entsprechender Twitter Handle existiert natürlich auch schon (@EclipseEE4J). Der neue Name soll aber zur Erhaltung der Kompatibilität und Kontinuität keine Auswirkungen auf bereits bestehende oder zukünftige Packagestrukturen haben. Der Prefix javax kann auch zukünftig verwendet werden.

In einem nächsten Schritt gilt es, die Java-EE-Technologien zu Gunsten der Eclipse Foundation zu relizensieren. Das beinhaltet u. a. die RIs (Reference Implementations), Projektdokumentation und – Achtung, jetzt wird es wirklich wichtig – das TCK (Technology Compability Kit). Erst wenn dieser Schritt erfolgt ist, geht Java EE auch offiziell in die Eclipse Foundation über und ein etwaiges Engagement von Dritten, wie IBM oder Red Hat, kann nicht mehr verloren gehen.

Fazit

Java und Java EE gehen in die Open-Source-Community über! Ein langersehnter Traum von James Gosling, dem Urvater von Java, aber nicht nur von ihm, scheint Realität zu werden. Wenn sich alles so positiv entwickelt, wie es sich derzeit abzeichnet, dann ist das eine Riesenchance für den Java-Enterprise-Standard. Die Community erhält deutlich größeren Einfluss auf die zukünftige Ausrichtung. Der Prozess zur Weiterentwicklung von Java EE wird wesentlich agiler. Jährliche oder sogar halbjährliche Releases sind durchaus realistisch. Der auf Microservices ausgerichtete Nichtstandard-Spin-off von Java EE – Eclipse MicroProfile – hat vorgemacht, wie es funktionieren kann, wenn führende Köpfe der Community an einem Strang ziehen. Allerdings gibt es auch mehr als genug Beispiele aus der Vergangenheit, in denen ein Übergang eines kommerziellen Produkts hin zu Open Source nicht funktioniert hat. Denn seien wir einmal ehrlich: Wahrscheinlich wird niemand von uns jemals einen Fork von Java EE aufmachen und im Anschluss selbstständig weiterentwickeln.

Der Erfolg des Open-Source-Projekts Java EE wird auch in Zukunft stark vom kommerziellen Interesse etlicher Beteiligter abhängen. Solange sich hier eine Win-Win-Situation schaffen lässt, ist alles in Ordnung. Sollte allerdings einer der Beteiligten versuchen, sich in eine privilegierte Rolle zu drängen, ist ein Auseinanderdriften des Standards in mehrere proprietäre Derivate zu befürchten. Dies gilt es im Auge zu behalten und als Community im Falle eines Falles gezielt dagegen vorzugehen. Wir haben den zukünftigen Erfolg von Java EE also selbst in der Hand. In diesem Sinne: Stay tuned!

Geschrieben von
Lars Röwekamp
Lars Röwekamp
Lars Röwekamp ist Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise und Mobile Computing, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen. Lars Röwekamp, Autor mehrerer Fachartikel und -bücher, beschäftigt sich seit der Geburtsstunde von Java mit dieser Programmiersprache, wobei er einen Großteil seiner praktischen Erfahrungen im Rahmen großer internationaler Projekte sammeln konnte.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: