Kommentar

Java EE 7 und die vertane Chance

Hartmut Schlosser

Java EE 7 ist ein Datums-getriebenes Release, hatte Oracles Middleware Vice President Dennis Leung in seiner JAX-Keynote im April 2012 verkündet. Mitte 2013 werde man der Community garantiert ein Java EE 7 Release präsentieren, egal welches Feature-Set bis dahin abgeschlossen würde. Damit, dass in Java EE 7 nun allerdings die gesamten PaaS-Spezifikationen ausgelassen werden, hatte damals niemand gerechnet. Auch wenn in letzter Zeit der ein oder andere Unkenruf über das schleppende Vorankommen der Java EE 7 Specs zu vernehmen war, schien Oracles Aussage „We’re moving Java EE into the Cloud“ bis zuletzt in Stein gemeißelt.

Nun ließ Java EE Spec Lead Linda DeMichiel am vergangenen Freitag die Bombe platzen: Der Java-EE-Expertengruppe wurde der Vorschlag unterbreitet, die Spezifikationen zum Platform-as-a-Service-Support auf Java EE 8 zu verschieben – geplantes Release-Datum: Mitte 2015. Unweigerlich fühlt man sich an das jüngste „Jigsaw-Desaster“ erinnert: den Vorschlag, eines der wichtigsten für JDK 8 geplanten Features, die Modularisierung der Plattform, auf Java 9 im Jahr 2015 zu verschieben. The Register schreibt, bei Oracle werde es langsam zur Gewohnheit, überambitionierte Roadmaps vorzustellen, die dann nicht eingehalten werden. Doch anders als bei der Jigsaw-Verschiebung bleibt der große Aufschrei der Community über das Brechen der Java-EE-7-Roadmap aus. Weshalb ist das so?

Ein kurzer Blick zurück. Schon kurz nach der Sun-Übernahme durch Oracle konnte man auf allen Strategie-Papieren aus Redwood Shores lesen, PaaS sei der nächste logische Schritt für Java EE. Während Java EE 6 Services bereitgestellt hatte, sollte die Java EE 7 Plattform selbst ein Service werden. Hierfür sollten neue Plattform-Rollen definiert, Metadaten für Dinge wie Service-Bereitstellung, Elastizität, Ressourcen-Teilung bereitgestellt, nützliche Cloud-Schnittstellen wie JAX-RS Client API, Caching API und JSON hinzugefügt werden. Und schließlich sollten existierende APIs um Multitenancy-Support erweitert werden.

Oracles Java-Evangelist Arun Gupta hatte diesen Schlachtplan in folgende Slides gegossen:

Wie Linda DeMichiel auf der Java-EE-Mailing-Liste nun schreibt, soll an diesem strategischen Setting nichts Grundlegendes geändert werden. Eine Verschiebung der Spezifizierung sei aber vonnöten, da die Cloud-Technologien noch so jung, der Markt dementsprechend unreif und ein allgemein akzeptierter Standard derzeit schwer erreichbar sei. Und schaut man sich die Reaktionen auf der Mailing-Liste an, so ist der Grundtenor hier nicht Entrüstung, sondern Zustimmung.

Red Hats Pete Muir schreibt, man habe bei Red Hat schon lange die Position vertreten, dass die Java EE Community noch nicht bereit für die Standardisierung der Cloud sei. Als Beweis führt er das eigene Cloud-Angebot OpenShift an.

Java-Champion Antonio Goncalves ist erleichtert, dass man nicht den Fehler macht, zu früh einen Industriestandard zu definieren, den niemand nutzen will – wie schon bei manch anderem JSR geschehen. Allerdings bedauert er, dass bereits so viel Energie in die PaaS-Specs gesteckt wurden – Energie, die man besser für dringendere Probleme wie ein Logging-API aufgewendet hätte.

Am interessantesten ist der Kommentar von David Blevins, TomEE-Mastermind und Gründer der Projekte OpenEJB und Geronimo. Blevins schließt sich der Einschätzung seiner Kollegen an und fügt hinzu, dass Java EE bereits jetzt zu 90 Prozent „Cloud-ready“ sei. Mit den restlichen 10 Prozent befinde man sich deutlich in der Phase der Experimente, nicht in der Phase der Standardisierung. Blevins ruft allen die Rolle des Standardisierungsgremiums JCP in Erinnerung: Anbieter stellten Innovationen bereit. Danach sei es die Aufgabe des JCP, kollektiv getragene Standards herauszukristallisieren.

Genau in diese Kerbe schlägt auch Linda DeMichiels Bemerkung auf dem The Aquarium Blog, die Java-EE-Expertengruppe verfolge einen konservativen Ansatz und versuche, die Dinge „von vorneherein richtig anzugehen“. Keine Experimente also, sondern eine Standardisierung ex post. Im englischen Sprachraum hat sich für diese Art der Vorgehensweise der Begriff „Code first“ etabliert.

Und hier kommt wahrscheinlich der wahre Grund für die Entscheidung zum Vorschein, Java EE 7 ohne eine detaillierte PaaS-Spezifizierung auszugeben. Spätestens nach der Übernahme der Java-Hohheit durch Oracle wurde das frühere JCP-Prinzip, erst zu spezifizieren und dann zu implementieren („Spec first“) verworfen. Heute wird etwa im OpenJDK-Projekt zunächst funktionierender Code produziert, dann spezifiziert.

Und genauso wird es nun in Java EE geschehen. Erst sollen sich funktionierende Lösungen durchsetzen, dann extrahiert man die Grundprinzipien und gießt sie in einen Industrie-Standard. Hat man diesen Paradigmenwechsel verstanden, den der JCP respektive Oracle vollzogen hat, dann ist auch die Entscheidung der Java-EE-Gruppe völlig nachvollziehbar – ob sie einem nun gefällt oder nicht.

Gefahr läuft man bei diesem Paradigma freilich, dass die Java-EE-Community den aktuellen Trends immer nur hinterherläuft – bzw. im schlimmsten Falle schlicht zu spät dran ist. Eine gute PaaS-Spezifizierung in Java EE 7 hätte indes das Potenzial gehabt, einen eigenen Trend zu setzen, dem wiederum die Anbieter gefolgt wären.

Die Musik wird somit erst einmal woanders gespielt: Bei CloudFoundry, CloudBees, OpenStack, OpenShift, Jelastic, Heroku oder auch bei den Klassikern Amazon Beanstalk, Google App Engine, Microsoft Azure. Und auch Oracle selbst hatte sich vor kurzem erst der Initiative CAMP angeschlossen, in dessen Rahmen bereits eine Spezifizierung einer PaaS vorgelegt wurde – unter Beteiligung von Oracle, Red Hat, CloudBees, Cloudsoft, Huawei, Rackspace und der Software AG.

Die Wolken-Musik spielt nun woanders, damit müssen wir uns wohl abfinden, liebe Java EE Community. Und so halten wir es am besten mit ZeroTurnarounds Jevgeni Kabanov, der auf der Java-EE-Mailingliste feststellt, dass es im Cloud-Bereich zwar eine rege Bewegung am Markt gibt, allerdings noch völlig unklar ist, welche Technologien, Methodologien und Philosophien sich als Gewinner erweisen werden. Jevgeni hofft, dass die Situation in zwei bis drei Jahren, zum Release von Java EE 8, etwas klarer ist – hoffen wir mit ihm.

Und wenn unsere Hoffnung erfüllt wird, dann sehen wir im Jahr 2015 zwei Mega-Releases Realität werden: Java 9 inklusive Jigsaw und Java EE 8 mit PaaS, nicht wahr? Allein stellt sich die Frage, welchen Glauben man Oracle-Roadmaps jetzt noch schenken sollte.

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

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