Kommentar

JavaOne 2016: Meine Meinung zum Java EE 8 Roadmap Update

Sebastian Daschner

Wie angekündigt hat Oracle auf der JavaOne 2016 die Pläne für die Zukunft von Java EE offen gelegt. Sebastian Daschner kommentiert die von Oracle vorgeschlagenen Änderungen.

Java EE Roadmap Update

Auf der Keynote der aktuell stattfindenden JavaOne hat Oracle die seit langem erwartete Reaktion hinsichtlich der Zukunft von Java EE gezeigt und dabei eine überraschend stark veränderte Roadmap vorgelegt.

Anil Gaur präsentierte den grundlegenden Plan für EE 8 und Java 9 in seiner Keynote, in der er die Änderungsvorschläge für Ausrichtung und Zielsetzung von Java EE im Allgemeinen sowie die Modifikationen an den JSRs im Besonderen vorstellte. Diese Updates werden gerechtfertigt durch angeblich veränderte Anforderungen in Zeiten von Cloud und Microservices.

Linda Demichiel stellte die Updates für die Java EE Roadmap nochmals detaillierter in ihrer Konferenz-Session vor.

Die Pläne umfassen ein (ziemlich aggressives) Roadmap Update für Java EE 8, das 2017 fertig gestellt werden soll, sowie eine darauf folgende Version 9 im Jahr 2018. Wichtiger sind jedoch die Veränderungen in Bezug auf die Zielsetzungen von Java EE und die konkreten Hinzufügungen bzw. Entfernungen von JSRs von der Plattform.

Um den neuen Anforderungen gerecht zu werden, möchte Oracle der EE-8-Spezifikation zwei neue JSRs hinzufügen, namentlich die JSRs „Configuration“ und „Health Check“. Die neuen JSRs zielen darauf ab, eine umfassende, externe Konfiguration von Anwendungen bzw. Health-Monitoring in einer standardisierten Form bereit zu stellen.

Die existierenden JSRs würden sich ebenfalls leicht umorientieren und den neuen Anforderungen sowohl hinsichtlich Resilienz als auch in Bezug auf Reaktivität angepasst werden. Auf lange Sicht sieht die Liste der Updates vor, Eventual Consistency, Mehrmandantenfähigkeit und eine stärkere Unterstützung für Sicherheitsstandards umzusetzen.

Allerdings plant Oracle auch, einige Spezifikationen von der Plattform zu entfernen, namentlich MVC, Management 2.0 und JMS 2.1. Diese Maßnahmen werden dadurch begründet, dass MVC und JMS „nicht mehr sehr relevant in der Cloud“ seien, während Management in der Vergangenheit keine weitreichende Anwendung gefunden habe. Die Pläne sehen außerdem vor, JCache nicht in eine zukünftige Version der Plattform einzubauen.

Meine Meinung

Zunächst einmal ist es sehr positiv, eine Reaktion von Seiten Oracles bezüglich des Fortschritts von Java EE zu sehen. Die Erweiterungen und Updates für die Plattform erscheinen mir ebenfalls sehr vernünftig, besonders, da sie die Anforderungen für Resilienz, Reaktivität, Eventual Consistency, Health Checks und Konfiguration abdecken. Dafür sind bereits einige Open-Source-Lösungen entstanden, beispielsweise Deltaspike, Adam Biens Breakr- und Porcupine-Projekte und Anbieter-spezifische Funktionalitäten wie der Reactive-Support in Jersey. Ich begrüße es sehr, wenn solche Features den Weg in die Plattform finden.

Hingegen ergeben die Entfernung von MVC und die Begründung dafür keinen Sinn für mich. Die letzten Umfragen haben gezeigt, dass ein großes Bedürfnis und Interesse besteht, (endlich) ein standardisiertes, Action-basiertes MVC-Framework in Java EE zu integrieren. Auch die JSR-371-Expertengruppe war sehr aktiv und die Spezifikation ist bereits sehr weit fortgeschritten. In meinen Kundenprojekten gab es ebenfalls einen ständigen Bedarf für einen solchen Ansatz, der bisher immer über eine Eigenlösung oder Drittpartei-Komponente abgedeckt werden musste. Obwohl Client-seitige JavaScript-Frameworks, die via REST und JSON mit Backends kommunizieren, recht populär sind, ist es zweifellos jetzt und auch in Zukunft nötig, Server-seitig gerenderte Seiten zur Verfügung zu stellen.

Ein weiterer JSR, der in EE 8 integriert werden sollte, ist JCache. Die Notwendigkeit für eine Caching-Funktionalität ist in modernen Enterprise-Systemen immer noch sehr präsent – insbesondere, wenn Hochverfügbarkeit ein Kriterium darstellt (auch wenn der JSR überarbeitet werden könnte, um endlich Standards für verteilte Caching-Mechanismen zu integrieren, die derzeit nur in Anbieter-spezifischen Lösungen enthalten sind).

Lesen Sie auch: JavaOne im Kreuzfeuer: “Java EE wird immer mehr zu Oracle EE” [Kommentar von Niko Köbler]

Meiner Meinung nach konzentriert sich Oracle viel zu stark auf die Cloud. Auch wenn das Deployen von Anwendungen in der Cloud sicherlich ein Ansatz ist, der von einer steigenden Anzahl von Entwicklern und Unternehmen verfolgt wird, ist es am Ende des Tages dennoch nur eine Art und vielen, um Anwendungen zu betreiben und auszuliefern. Übrigens habe ich in meinem Blogpost über „Lightweight Java EE“ ausgeführt, warum ich Application Server und leichtgewichtige Deployment Artefakte für einen sehr vernünftigen Ansatz für Enterprise-Anwendungen halte. Bei diesem Ansatz kommt es eigentlich nicht so sehr darauf an, wo der Application Server – bzw. der Container, der diesen enthält – läuft.

Die Anforderungen, die Entwickler zwingen, monolithische Anwendungen in verteilte Anwendungen (Stichwort „Microservices“) zu zerlegen, etwa Hochverfügbarkeit, Skalierbarkeit oder Unternehmensstrukturen, beeinflussen die System-Architektur und Programmiermodelle weitaus mehr. Deshalb ist es eine gute Sache, bereit für Deployments in ganz unterschiedliche Arten von Laufzeitumgebungen zu sein. Aber diese Anforderungen sollten nicht in eine einzige Ausrichtung der Plattform münden.

Was darüber hinaus zukünftig verbessert werden sollte, ist die Kommunikation Oracles mit der Community. All diese Änderungen wurden ohne jegliche Vorabinformation bekannt gegeben – weder auf den Mailinglisten, noch in den Experten-Gruppen. Womöglich wollte Oracle es einfach nur spannend machen und endlich wieder mal eine große News auf einer JavaOne enthüllen 😉

Wie dem auch sei, die Java EE Updates stellen in der Summe wirklich eine gute Nachricht dar, und die restlichen Punkte können hoffentlich durch das Engagement der Community und anderer Anbieter gelöst werden.

Was kommt als nächstes?

Wir können also mit Neugier und hohen Erwartungen auf die nahe Zukunft von Java EE blicken. Auch wenn wir noch nicht vollständig überzeugt sind, wie die Änderungen und Roadmaps sich auf Oracle-Seite umsetzen lassen, wollen wir optimistisch bleiben und auf das Beste hoffen.

Tun Sie mir nun bitte den Gefallen und klinken Sie sich in den Prozess und die Diskussionen ein. Beginnen Sie beispielsweise mit dem Ausfüllen des Glassfish Survey. Auch Kommentare auf den JSR Mailing-Listen sind sehr willkommen – auch und besonders von Nicht-JCP- oder Nicht-Expertengruppen-Mitgliedern. Jeder profitiert vom direkten Feedback der Entwickler – sowohl zur allgemeinen „EE-Politik“ als auch zu den verschiedenen technologischen Aspekten.

Was ist Ihre Meinung? Feedback ist herzlich willkommen.

Dieser Artikel ist zurerst erschienen auf Sebastian Daschners Blog.

 

Verwandte Themen:

Geschrieben von
Sebastian Daschner
Sebastian Daschner
Sebastian Daschner arbeitet als freiberuflicher Java Consultant, Softwareentwickler bzw. -architekt und programmiert begeistert mit Java (EE). Er nimmt am Java Community Process teil, ist in der JSR 370 Expert Group vertreten und entwickelt an diversen Open-Source-Projekten auf GitHub. Er ist ein Java Champion und arbeitet seit über 6 Jahren mit Java. Darüber hinaus benutzt Sebastian auch intensiv Linux und Containertechnologien wie Docker. Er evangelisiert Java- und Programmierthemen unter https://blog.sebastian-daschner.com und auf Twitter unter @DaschnerS.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: