Dreimal Zukunft und zurück – Perspektiven für Java EE 8

Inhaltsverzeichnis

Ausgangspunkt war im April dieses Jahres Josh Juneas schonungslose Analyse der konkreten Aktivitäten in den in der Java EE 8 vorgesehenen Spezifikationen seit 2015. Als Expert-Group-Mitglied in den JSRs 372 (JavaServer Faces 2.3) und 368 (Java Message Service 2.1) hat er einen genauen Blick auf Oracles Beteiligung an der Entwicklung in Mailinglisten und Commits auf GitHub untersucht und den vorigen Verdacht der Community mit Zahlen unterlegt: Demzufolge ist die Beteiligung des Unternehmens zum Stillstand gekommen – und das bereits im November 2015.

Nachdem im zentralen JSR 366 für Java EE 8 ein erster Early Draft schon für das erste Quartal 2015 und die finale Version für das dritte Quartal 2016 angekündigt wurde, hatte Oracle im Juni 2015 eine Verschiebung um etwa ein halbes Jahr angekündigt. Diese wurde von der Community teilweise noch begrüßt und als Chance zur aktiveren und nachhaltigeren Beteiligung angesehen. Unterm Strich steht aber die Entwicklung seit acht Monaten in allen von Oracle vorangetriebenen Spezifikationen still. Je nach Auslegung der von Oracle veranschlagten Verschiebung auf das erste Halbjahr 2017 könnte man durchaus noch davon ausgehen, dass alles in Ordnung sei. So erschien letzte Woche das The Register gegebene Interview mit Oracles Sprecher Mike Moeller gerade rechtzeitig. Er kam Ende 2015 von Marketo zu Oracle und hat offensichtlich einen klaren Cloud-Fokus. Die folgenden Statements werfen allerdings schon ein paar Fragen auf:

"Oracle is committed to Java and has a very well defined proposal for the next version of the Java EE specification – Java EE 8 – that will support developers as they seek to build new applications that are designed using micro-services on large-scale distributed computing and container-based environments on the Cloud."

Wird eingangs noch von Java gesprochen, folgt sogleich der Java-EE-8-Bezug. Meint er hier nun Java SE oder wirklich Java EE? Dann geht es nahtlos mit Microservices und verteilten Anwendungen in der Cloud weiter. Gab's hierzu nicht schon einen ersten, dann aber verschobenen Versuch bei Java EE 7?

Bei Moeller heißt es weiter:

"Oracle is working closely with key partners in the Java community to finalize the proposal and will share the full details with the broader Java community at JavaOne in September."

Die Community begrüßt die Aussage und stößt einen erleichterten Seufzer aus – voller Vorfreude auf die JavaOne. Aber was genau kann jetzt alles passieren? Und welche Auslegungen lassen sich auf Basis von Moellers vagen Äußerungen treffen?

Java EE 8 als Maintenance Release

Wer davon ausgeht, dass Moeller nicht genau wusste, was er da sagte, und der zweite Teil des oben zitierten Satzes eine gesunde Mischung aus Produkthalbwissen enthält, könnte zum Schluss kommen, dass er eigentlich nur von sich gegeben habe, dass Oracle weiterhin zu Java EE 8 stehe.

Die Aussagen unter anderem auf der JPA-Mailingliste legen allerdings nahe, dass für Java EE 8 keine grundlegenden Weiterentwicklungen geplant waren und viele der Spezifikationen nur als sogenanntes Maintenance Release beteiligt sein werden. Dann würde die Version 8 tatsächlich ein paar neue Funktionen und Updates erhalten, aber keine grundlegenden Neuerungen. Im zentralen JSR 366 ist noch nicht mal der JSR 107 (JCache) genannt, auch nicht MVC 1.0. Um das zeitliche Ziel zu erreichen, bleibt im Idealfall noch weniger als ein Jahr Zeit. Java EE 7 hat vom Early Draft bis zur finalen Version 13 Monate benötigt. Allerdings dauerte es länger, zum Early Draft zu kommen. Schaut man sich den von Java EE 8 an, dann sind die Änderungen sehr überschaubar. Vielleicht ist das die am wenigsten aufregende Variante der Zukunft, aber vermutlich die wahrscheinlichste.

Java EE 8 ohne Oracle – nur einmal oder fortan immer?

Mit deutlichem Schwerpunkt auf dem zweiten Zitat, in dem Oracle mit wichtigen Partnern in der Java-Community an einem neuen Vorschlag arbeitet, bleibt die Lösung offen, dass Java EE 8 ohne Oracle fertiggestellt wird. Was sich einfach durch einen Wechsel des "Specification Lead" erreichen ließe, hat signifikante rechtliche Implikationen. Nachzulesen im JCP-Process-Dokument behält sich Oracle das finale Veto bei allen Plattformen bei. Um das bei Java EE 8 zu umgehen, würde es wohl eine grundlegende Änderung im JCP benötigen oder gegebenenfalls Zusatzverträge mit den nicht näher benannten "Schlüsselpartnern". Laut Oliver Gierke sind lizenzrechtliche Gründe ein deutlicher
Hindernisgrund für dieses Szenario. Das ist aber sicherlich auch nichts, was sich nicht mit neuen Verträgen regeln ließe. Ob das einmalig nur für Java EE 8 passieren würde oder quasi einer Staffelstabübergabe für die Zukunft gleichkommt, weiß natürlich niemand. Aber grundsätzlich bleibt die Frage, warum sich Oracle hier die Entscheidungsgewalt über die Zukunft einer zentralen Plattform aus den Händen nehmen lassen soll. Laut Business Insider trägt Java EE direkt oder indirekt mit 70 Prozent zu Oracles Gewinn bei.

Wer hier als Partner in Frage kommt, ist reine Spekulation. Wünschenswert wäre sicherlich Red Hat, nachdem hier bereits umfangreiche Erfahrung mit zentralen JSRs wie Context und Dependency Injection (CDI) vorliegen und auch einige eigene Referenzimplementierungen im Rahmen von Open-Source-Communities implementiert werden. Aber leider hat das Unternehmen ja gerade eine eigene Initiative rund um ein Micro-Profil mitgestartet. Selbst wenn Mark Little, Red Hats VP of Middleware, das weitere Engagement zu Java EE deutlich betont, lässt diese Initiative Raum für neue Spekulationen.

Java EE 8 wird Java SE + Cloud APIs (Serverless)

Beim erneuten Blick auf den Teil von Moellers Zitat, wo es um Cloud und verteilte Systeme geht, sei an die Aussage der Analysten von Gartner erinnert, dass klassische Anwendungsplattformen tot seien. Träfe das zu, wäre es naheliegend, sich vom Applikationsserver an sich und einer umfangreichen Sammlung von Referenzimplementierungen zu verabschieden und etwas "leichtgewichtiger" auf Java SE zu setzen. Vielleicht gibt es auch schon eine implizite Referenzimplementierung von Oracle mit dem Java Cloud Service. Hier finden sich Begriffe wie "Managed Servers" und "Scaling". Vielleicht implementiert der Service ja bald die Java EE APIs, aber ohne Applikationsserver darunter. Inhaltlich wäre das sinnvoll. Die APIs sind bekannt und werden von vielen Entwicklern beherrscht. Hier die API von der Implementierung loszulösen und eine neue, einfachere Runtime in der Cloud anzubieten, ist ein logischer Schritt. Am Ende wird wohl auch das Micro-Profile in diese Richtung wandern. Vor allem deswegen, weil gerade ja der neue Serverless-Hype aufkommt. Damit würde Java EE 8 in Richtung Amazons Lambda-Architektur gehen.

Es ist jedoch nicht anzunehmen, dass das in einem Jahr überhaupt möglich ist. Es sei denn, Oracle hat die Ressourcen, die von Java EE 8 abgezogen wurde, schon seit längerem intern auf diesen Weg gebracht. Dann bliebe noch die Grundsatzfrage, wie sich solch ein grundlegender Strategiewechsel quasi im Überholmodus neben dem JCP fahren ließe und darauf wieder zurück in den JCP einschert. Selbst wenn dieser Ansatz sehr modern und zukunftsfähig aussieht, bleibt die Machbarkeit sicherlich die größte Frage.

Java EE 8 wird "reactive" und wechselt komplett die Richtung

Noch eine spannende Alternative, die genauso aus der Luft gegriffen ist wie alle anderen: Java EE beugt sich einem alternativen Standard. Vielleicht Spring? Pivotal ist ein vergleichsweise kleiner Fisch für Oracle, und schon lange gab es keine großen Übernahmen mehr. Spring entwickelt sich im Kern in Richtung reaktiver Anwendungsentwicklung weiter. Die Version 5 soll hier einen starken Fokus legen. Nachdem Java EE den zeitgemäßen Anforderungen an Anwendungen nach nicht gewachsen ist, wäre es ein durchaus nachvollziehbarer Schritt, diesen alternativen Weg einzuschlagen. Vor allem weil Spring ja schon viele der Java EE APIs kennt und damit viel einfacher Java EE auf die Java-SE-Basis stellen könnte. Und Spring Boot ist bereits klar auf Microservices ausgerichtet und Apache-lizensiert, ließe sich also einfach in einen JSR oder sogar eine Referenzimplementierung überführen.

Allerdings muss hier ganz klar sein, dass Oracle nicht gerade für Spenden in Richtung Open Source bekannt ist. Und die Definition von Sping Boot als quelloffene Referenz für eine Java EE 8 Microservice Edition erscheint doch zu transparent und offen.

Fazit

Unterm Strich ist keine der genannten Alternativen dazu geeignet, Begeisterung für Java EE 8 zu wecken. Am realistischsten ist sicherlich das Maintainance-Release-Szenario. Am zukunftsfähigsten wäre die Lambda/Cloud-Variante. Vielleicht gibt es aber im September auch eine Überraschung auf der JavaOne, und Oracle bestärkt sein Commitment zur Plattform durch sichtbare Wiederaufnahme der Aktivitäten und einer visionären Führung. Nachdem die Specifications Leads Linda Demichiel und William Shannon schon während der Diskussionen um den Richtungswechsel bei Java EE 7 von Cloud- zu Entwickler-Produktivität vielfach betont hatten, dass ein Standard nicht innovativ sein, sondern etablierte Vorgehensweisen zusammenfassen müsse, würde das einem weiteren 180-Grad-Richtungswechsel entsprechen.

Was auch immer im September wirklich herauskommt, bleibt abzuwarten. Die Einschränkungen von zentralen Anwendungsplattformen bei der Umsetzung moderner Businessanforderungen sind kaum mehr zu leugnen. Jegliche halbherzige Modernisierung wird an diesem Punkt auch nur aussehen wie eine halbherzige Lösung.

Markus Eisele
ist Java Champion, früheres Mitglied der Java EE 7 Expert Group, stellvertretender Java-Community-Leiter der DOAG, Mitbegründer vom JavaLand und etablierter Sprecher auf Java-Konferenzen auf der ganzen Welt. Er arbeitet für Lightbend. (ane)