Zukunft von Java EE

In der Enterprise Java Welt rumort es derzeit wieder gewaltig. Begonnen hat alles vor über einem Jahr, als schleichend und ohne Kommentar die Arbeiten an den von Oracle geführten JSRs (Java EE 8) eingestellt wurden. Die Java EE Guardians [1] haben sich daraufhin formiert, um Oracle wenigstens zu einer Stellungnahme zu zwingen. Zwar ließ sich Oracle nicht gleich aus der Reserve locken, bekräftige dann aber tatsächlich im Sommer immerhin sein zukünftiges Interesse an Java EE. Zuvor waren bereits Gerüchte kursiert, der Datenbank-Riese würde den eigentlich Community getriebenen Spezifikationsprozess trotz aller Proteste sang- und klanglos einstampfen. Als Folge davon stand sogar im Raum, einen Fork von der Java EE Spezifikation abzuzweigen, der aber rechtlich auf sehr wackligen Beinen gestanden hätte.

Die Details zu seinen Plänen wollte Oracle zwar erst auf der JavaOne Anfang Oktober verkünden, man skizzierte aber immerhin schon einige Wochen vorher die grobe Idee ([2], [3]):

  • konsequente Ausrichtung der Java Enterprise Edition auf Cloud-Anwendungen
  • Verwendung neuer Architektur- und Programmierkonzepte (Microservices und reaktive Programmierung)
  • bessere Integration von NoSQL-Datenbanken

Die Java-Community wartete dann gespannt auf die Eröffnungs-Keynote, die man sogar im Livestream aus der Ferne verfolgen konnte (Aufzeichnung unter [4]). Dort wurde zunächst ein sehr sportlicher Zeitplan vorgestellt. Oracle will tatsächlich Java EE 8 bis Ende 2017 herausbringen, wobei die Agenda sich nochmal deutlich verändern wird. Zudem sollen bereits parallel die Arbeiten an Java EE 9 beginnen, welches nur ein Jahr später (2018) erscheinen soll. Das klingt alles etwas zu optimistisch, insbesondere da gerade erst wieder Java SE 9 um einige Monate verschoben wurde. Man darf also gespannt sein. Vielleicht hat Oracle im letzten Jahr auch bereits stillschweigend an den APIs gearbeitet und lässt sie jetzt mal eben im Vorübergehen einfließen. Dass damit der Java Community Process (JCP) komplett übergangen wird, würde zum aktuellen Bild von Oracle passen.

In Oracles Revised Proposal tauchten auf einmal ganz neue JSRs auf, andere sind nicht mehr gelistet und wurden auch nicht mal in der Keynote erwähnt. Dementsprechend wurde auf Twitter wild spekuliert, bis dann Linda Demichiel in ihrer Session einen Tag später mehr Details zur Roadmap verriet. Um den neuen Anforderungen wie Cloud und Microservices gerecht zu werden, wurden mit Configuration und Health Check zwei neue JSRs in Java EE 8 aufgenommen. Ziel ist es sowohl fortgeschrittene und von außerhalb aufrufbare Konfigurationsmöglichkeiten und Monitoring über Health-Checks in einer standardisierten Form anzubieten. Bestehende JSRs müssen zudem an die neuen Anforderungen (Resilience, reaktiv) angepasst werden. In der längerfristigen Planung (Java EE 9) sind auch noch Eventual Consistency, Multi-Tenancy und die erweiterte Unterstützung von Security Standards im Gespräch.

Verwunderlich ist, dass Oracle bisher die Bemühungen der im Sommer entstandenen MicroProfile Initiative [5] ignoriert hat. Dort haben sich nämlich IBM, Payara, Tomitribe, Red Hat und Vertreter der Java Community bereits Gedanken über die Optimierung von Java EE im Kontext von Microservice Architekturen gemacht. Microprofile.io thematisiert somit die gleichen Themen, die nun auch Oracle für Java EE 8 + 9 für wichtig erachtet und hat sogar schon eine erste, wenn auch noch sehr leichtgewichtige Lösung präsentiert. Es bleibt also abzuwarten, ob Oracle hier das Rad neu erfindet oder doch noch das Gespräch mit den Java EE Partnern sucht.

Für Java EE 8 müssen laut Oracle im Gegenzug zunächst mal drei JSRs weichen:

  • MVC 1.0
  • Management 2.0
  • JMS 2.1

Als Begründung wurden die fehlende Relevanz von MVC und JMS in Cloud-Anwendungen und die zu geringe Nutzung von den Management-Schnittstellen genannt. Insbesondere das Entfernen von MVC verwundert allerdings. Einerseits werden wir auch in Zeiten von Cloud-Anwendungen nicht nur noch Single-Page-Applications programmieren, sondern auch weiterhin Action-basierte klassisch auf dem Server gerenderte dynamische Webseiten entwickeln. Und da ist MVC eine leichtgewichtigere Variante zum komponentenbasierten Ansatz vom Java EE Veteran JSF. Das Spring Framework hat es mit seinem erfolgreichen proprietären MVC Framework schon viele Jahre vorgemacht. Im Internet findet man derzeit einige weitere Fürsprecher, die für den Verbleib von MVC in Java EE 8 plädieren ([6], [7]).

Ganz besonders bedauernswert ist dieses Verhalten von Oracle, weil in der letzten großen Umfrage vor der Festlegung der Ziele für Java EE 8, das Thema MVC von der Community als relativ wichtig erachtet wurde. Zudem war die Expert Group des JSR 371 sehr aktiv und hat die Arbeiten bis auf das fehlende TCK nahezu abgeschlossen. Das ist ein Schlag ins Gesicht der Expert Group Mitglieder aus der Community, deren Bemühungen der letzten zwei Jahren damit zunichtegemacht würden.

Aber immerhin möchte sich Oracle auch diesmal wieder die Absolution für sein Vorgehen in Form einer Umfrage abholen. In der Hoffnung, dass unsere Wünsche diesmal erhört werden, haben wir noch bis zum 21.10.2016 Zeit, die Umfrage auszufüllen ([8]). Möglicherweise kann das Ergebnis Oracle diesmal doch noch umstimmen.

[1] Java Enterprise Wächter: http://blog.oio.de/2016/04/06/java-enterprise-waechter/
[2] Oracle Unveils Plan to Revamp Java EE 8 for the Cloud: https://www.infoq.com/news/2016/08/oracle-java-ee-cloud
[3] Oracle sieht “reaktives Programmiermodell” für Java EE 8 vor: https://jaxenter.de/oracle-javaee-release-45210
[4] Java One Keynote: https://www.oracle.com/javaone/on-demand/index.html
[5] MicroProfile.io: http://microprofile.io/
[6] Why MVC 1.0 is important for Java EE 8: http://blog.kaltepoth.de/posts/2016/10/07/why-mvc-1-0-is-important-for-java-ee-8.html
[7] Java EE 8 without MVC? https://medium.com/@lefloh/java-ee-8-without-mvc-66a051807e53#.fzah3ycw7
[8] Java EE Community Survey: https://glassfish.java.net/survey/

Short URL for this post: http://wp.me/p4nxik-2Ko
This entry was posted in Java EE, Politics and tagged , , , , . Bookmark the permalink.

Leave a Reply