JavaOne 2016

Ergebnisse der JavaOne 2016: „Java EE 9 könnte das Konzept des Application Server komplett abschaffen“

David Heffelfinger
javaone

Die Zukunft von Java EE wurde auf der zurückliegenden JavaOne ausgiebig diskutiert. David Heffelfinger war vor Ort mit dabei und fasst die wichtigsten Ergebnisse zusammen.

Letzte Woche fand die jährliche JavaOne-Konferenz in San Francisco statt. Ich hatte die Möglichkeit, bei der Konferenz dabei zu sein und durfte auch einen Vortrag halten: „Java EE Beyond the Basics.“ Die Session war gut besucht und hat viel Feedback hervorgerufen.

Eingeleitet wurde die JavaOne durch die Eröffnungs-Keynote, in der Anil Gaur, Group Vice President of Engineering bei Oracle, einen Überblick über Oracles Pläne für Java EE gegeben hat. Das wichtigste Vorhaben ist dabei, es einfacher zu machen, Java-EE-Anwendungen in der Cloud zu deployen. Java EE 8 soll ein Migrationspfad in diese Richtung darstellen, während Java EE 9 einen vollständigeren Cloud-Support aufweisen soll.

In diesem Artikel wollen wir uns darauf konzentrieren, was auf der JavaOne in Hinblick auf Java EE 8 und Java EE 9 diskutiert wurde. Alle Redner betonten dabei, dass die Pläne für Java EE 8 und Java EE 9 sich noch einer frühen Phase befinden und sich jederzeit ändern können. Der gegenwärtige Zeitplan sieht vor, Java EE 8 zur JavaOne 2017 zu veröffentlicht und Java EE 9 in ungefähr zwei Jahren.

Java EE 8

Die vorgeschlagenen Neuerungen für Java EE 8 bringen keine radikalen Veränderungen, sondern sind wie erwähnt als Migrationspfad für die Entwicklung und das Deployment in Cloud-Umgebungen gedacht. Als vor ein paar Jahren die Planungen für Java EE 8 begannen, war die „Cloud“ noch kein derart präsentes Thema wie heute. Mit dem Aufstieg der Cloud-basierten Anwendungen wurde indes klar, dass die alten Pläne für Java EE 8 geändert und auf die neuen Anforderungen ausgerichtet werden müssen.

Die ursprüngliche Ankündigung für Java EE 8 beinhaltete Updates für verschiedene Java-EE-Spezifikationen, inklusive Contexts and Dependency Injection (CDI) 2.0, Java Message Service (JMS) 2.1, Servlet 4.0, das Java API für RESTful Web Services (JAX-RS) 2.1, Java Server Faces (JSF) 2.3, Java EE Management API  2.0, das Java API für JSON Processing (JSON-P) 1.1 und Bean Validation 2.0. Die Planung beinhaltete auch einige neue Java-EE-Spezifikationen wie das Java API für JSON Binding (JSON-B) 1.0, Model-View-Controller (MVC) 1.0 und ein neues Java EE Security API.

Mit dem neuen Fokus auf Cloud und Microservice Deployment wurde das alte Konzept nun verändert, indem zwei neue Java EE APIs hinzugefügt und gleichzeitig zwei ursprünglich angekündigte APIs fallen gelassen wurden. Die überarbeitete Pläne für Java EE 8 beinhalten ein neues Health Check API als Standard, um den Zustand einer Anwendung zu überprüfen. Die jetzige Planung sieht vor, einen spezifischen Kontext-Pfad zu haben, der über einen RESTful-Web-Service-Aufruf angesprochen werden kann. Zurückgeliefert werden soll ein JSON String mit Parametern für die „Gesundheit“ einer Anwendung, also Dinge wie Status Codes, Warnungen, Korrektheit der Dependencies, etc.

Das überarbeitete Konzept für Java EE 8 beinhaltet zudem ein neues Java EE API zur standardisierten Konfiguration von Java-EE-Anwendungen. Dieser neue JSR wird Ideen von bereits verfügbaren Lösungen wie Apache Tamaya und DeltaSpike übernehmen und sie in den neuen Java-EE-8-Standard integrieren.

Besonders kontrovers am neuen Vorschlag ist der Wegfall einiger JSRs, die ursprünglich für Java EE 8 geplant waren: JMS 2.1, das Java EE Management API 2.0 und MVC 1.0. Der jetzige Plan sieht vor, Java EE 8 mit JMS 2.0 auszuliefern, also der aktuellen Version von JMS, die bereits in Java EE 7 enthalten ist. Ich habe zwar nicht explizit gehört, ob das Management API komplett fallengelassen oder die gegenwärtige Version in Java EE 8 integriert werden soll. Ich würde aber vermuten, dass im Sinne der Rückwärtskompatibilität das alte Management API immer noch dabei sein wird.

MVC ist ein neues Aktions-orientiertes Framework, um webbasierte Anwendungen zu entwickeln. Ursprünglich als Teil von Java EE 8 geplant, beinhaltet das neue Proposal kein MVC mehr. Begründet wird dieser Schritt damit, dass die Industrie mittlerweile auf reine JavaScript/HTML-Clients setze, die RESTful Web Services auf dem Server aufrufen.

Java EE 9

Laut mehreren Referenten werden Oracle und die Java-Community nicht auf die Veröffentlichung von Java EE 8 warten, um mit der Arbeit an Java EE 9 zu beginnen. Die Entwicklung von Java EE 9 soll stattdessen direkt starten. Eine der vorgeschlagenen Veränderungen in Java EE 9 ist der Ausbau von JAX-RS um Non-blocking I/O, Sicherheitsstandards wie OAuth und OpenID sowie „First Class Support“ für JSON processing.

Bereits seit Java EE 7 enthält Java EE ein JAX-RS Client API. Einige nun angedachte Verbesserungen für das Client API beinhalten die Unterstützung für das Circuit-Breaker Designpattern und ein reaktives Client-API. Das Circuit-Breaker Designpattern verhindert das Aufrufen von Services nach einer vorher festgelegten Anzahl an Fehlschlägen – stattdessen soll es zu einer gecachten Antwort bzw. einer Fehlermeldung kommen.

Was die reaktive Programmierung anbelangt, so lautet der Plan, Ideen aus existierenden Frameworks wie RxJava, Akka oder Reactor zu standardisieren.

Darüber hinaus ist ein neues Event-API für das Event-Handling in Cloud-Anwendungen für Java EE 9 geplant. Obwohl mehrere bestehende Java EE APIs bereits Events unterstützen, ist keine von ihnen sonderlich gut für Cloud-Szenarien geeignet.

Java EE 9 wird zudem auch die Unterstützung von NoSQL-Datenbanken wie Cassandra, HBase, MongoDB, CouchDB, etc. beinhalten. Es ist zwar denkbar, den JPA-Standard um NoSQL-Support zu erweitern. Wahrscheinlicher ist allerdings, dass es zu einem komplett neuen NoSQL-spezifischen API kommen wird.

Weiterhin wird Java EE 9 ein State Management API aufweisen, das möglicherweise auf das NoSQL API aufgesetzt wird. Beim Deployen von Anwendungen in der Cloud kann es vorkommen, dass mehrere Services zeitgleich Veränderungen an einem Objekt vornehmen wollen. Diese Veränderungen müssen zusammengeführt werden, um sicherzustellen, dass die Modifikationen aller Services auf sämtliche Kopien eines Objektes angewendet werden. Genau das soll das neue State Management API leisten.

Zum Weiterlesen: JavaOne 2016: Meine Meinung zum Java EE 8 Roadmap Update

Das derzeit angestrebte Java EE 9 beinhaltet außerdem Support für Multi-Tenancy, wodurch sich einzelne Java-EE-Anwendungen, abhängig vom gewählten Mandanten, leicht unterschiedlich verhalten können. Beispielsweise könnte sich abhängig vom Mandanten das Aussehen oder die Usability verändern, oder es könnte auf andere Datenquellen zugegriffen werden.

Eine weitere vorgeschlagene Änderung ist die Möglichkeit, Anwendungen so in der Cloud zu deployen, dass sie Dienste von Cloud-Service-Providern nutzen. In diesem Sinne wurde während der Java EE 8/9 BOF-Session angemerkt, dass Java EE 9 das Konzept des „Application Server“ komplett abschaffen könnte, um es mit Java-SE-9-Modulen zu ersetzen. In dieser neuen Idee würde eine Java-SE-Anwendung verschiedene Java-EE-Module verwenden (z.B. ein Modul für JPA, ein anderes für JAX-RS, etc.), während die Anwendung als JAR gepackt und an einen Cloud Provider übergeben würde. Dieses Konzept ähnelt damit dem, was WildFly Swarm bereits heute tut.

MicroProfile

Wie an Java EE interessierte Leser bereits wissen dürften, schien es für lange Zeit so, als gäbe es seitens Oracle keinen Fortschritt für Java EE 8 und gleichzeitig keine Erklärung für diese Verzögerung. Aus Sorge um den mangelnden Java-EE-Fortschritt gründeten sich mehrere Community-Initiativen, u.a. auch die MicroProfile-Initiative.

Das „Java EE Profile“-Konzept wurde in Java EE 6 eingeführt, mit der Idee, nur Teilmengen der Java-EE-Funktionalität für Anwendungen zur Verfügung zu stellen. Viele Anwendungen benötigen den vollständigen Stack nicht komplett, und so unterstützt das Java EE Web Profile bspw. „nur“ JSF, CDI, EJB „light“ (d.h. keine Unterstützung für Remote-Invokationen), JPA und Bean Validation. Anwendungen, die nur diese Teile des Java-EE-APIs benötigen, können also auf einen Web-Profile-konformen Applikationsserver wechseln. Der Server-Footprint ist dadurch deutlich kleiner als der eines vollständigen Java-EE-Servers.

Die MicroProfile-Initiative ist nun der Versuch, ein neues Profil zur Java-EE-Spezifikation hinzuzufügen, das speziell auf die Entwicklung von Microservices zugeschnitten werden soll. Die Initiative wird von vielen Anwendungsserveranbietern und Java User Groups unterstützt; namentlich IBM, Red Hat, Tomitribe und Payara auf Seiten der Anwendungsserveranbieter sowie die London Java Community und SouJava auf Seiten der Java User Groups.

Helfen Sie mit, die Zukunft von Java zu gestalten

Nachfolgend sind mehrere Möglichkeiten aufgelistet, wie Sie die Zukunft von Java EE mitgestalten können:

Verwandte Themen:

Geschrieben von
David Heffelfinger
David Heffelfinger
David Heffelfinger ist unabhängiger Consultant, mit einem Fokus auf Java, Java EE und J2EE. Er ist der Autor einiger Bücher über Java und verwandte Technologien, wie z.B. „Java EE 6 Development with NetBeans 7“, „Java EE 6 with GlassFish 3 Application Server“, etc. und arbeitet bereits seit über 20 Jahren in den Bereichen Software Architektur, Design und Development. Java ist bereits seit 1996 seine primäre Programmiersprache. Zudem wurde von David von TechBeacon als einer von 39 Java-Oberhäuptern und –Experten benannt und dazu aufgerufen ihm auf Twitter zu folgen: http://techbeacon.com/java-leaders-you-should-follow-twitter
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: