Suche
Enterprise Java: relevant or elephant?

JavaOne Tagebuch – Tag 1

Lars Röwekamp

Wie schon in den letzten Jahren, verteilen sich auch dieses Jahr die verschiedenen Veranstaltungen der JavaOne auf mehrere benachbarte Hotels. Auch wenn diese recht dicht beieinander liegen, kommen bei einer ungünstigen Auswahl an Sessions schnell 10km Fußmarsch am Tag zusammen. Also heißt es, entweder Laufschuhe an und die Health App meiner Apple Watch glücklich machen, oder mich alternativ vorher auf ein Themengebiet und somit auch auf ein Hotel festlegen. Ich habe mich für zweiteres entschieden und mir für heute – mit wenigen Ausnahmen – einige Sessions rund um das Thema „Enterprise Java“ auf die Agenda gelegt.

Java EE 8 – Status Quo

Da traf es sich gut, dass Linda DeMichiel, Specification Lead Java EE 8, heute einen Überblick über den aktuellen Stand von Java EE 8 gab. Übrigens, für diejenigen, die es bisher noch nicht wussten: Die neuen APIs in Java EE sind nicht durch Zufall in die Spezifikation gelangt, sondern das direkte Resultat einer zweistufigen Umfrage an die Java Enterprise Community.

ResultChart

Spitzenreiter der Umfrage wurde JSON Binding, was wenig verwundert, dicht gefolgt von Security Simplification und jCache. Und auch der Wunsch nach einem Action-based MVC Framework schaffte es immerhin noch in die Top 5! Damit die involvierten Specification Groups bei ihren Diskussionen den Fokus nicht verlieren, orientieren sich die anstehenden Neuerungen und Änderungen in Java EE an drei wesentlichen Themen. Zumindest die ersten beiden kennen wir bereits aus Java EE 7:

  • HTML 5 & Web Tier Enhancement
  • Ease of Development & CDI Alignment
  • Infrastructure for running in the Cloud

Wie aber ist nun genau der aktuelle Status der verschiedenen Specs? Um es gleich vorweg zu nehmen: Linda DeMichiel betonte mehrfach, dass die gezeigten (Power Point) Code-Beispiele nur als Ideen bzw. Diskussionsgrundlage zu verstehen sind, es sich aber mit hoher Wahrscheinlichkeit bis zum Final Release und somit bis 2017 – ja, das Datum stimmt leider – noch viele Änderungen ergeben werden.

Web Tier Enhancements

Bei der Spezifikation von JSON-B möchte man sich stark an bestehenden Lösungen orientieren. Als Beispiele wurden MOXy, Jackson, GSON, Genson und Xstream genannt. Es soll auf jeden Fall möglich sein, den unterliegenden JSON Binding Provider auszutauschen, um so z.B. auf einen schnelleren Mechanismus wechseln zu können. Wie zu erwarten, wird es, wie schon bei dem XML-Äquivalent JAX-B, Default-Mappings geben, die durch Annotationen überschrieben werden können. Nach dem Motto „All the way to the Database“ wird für JAX-RS so ein standardisierter Mechanismus geliefert, um „application/json“ on-the-fly zu unterstützen.

Dass man sich immer stärker auf JSON fokussiert und langsam aber sicher Abschied von XML nehmen möchte, zeigen die geplanten Änderungen in JSON-P 1.1 (JSON Processing). Im Wesentlichen handelt es sich um Aktualisierungen des bestehenden API, um mit der Evolution im JSON-Spezifikationsumfeld Schritt zu halten. Durch die Einführung von JSON Pointern können zukünftig Elemente innerhalb eines JSON Dokuments gezielt angesprochen und ausgelesen werden. Mit Hilfe von JSON Patch – der Umsetzung von RFC 6902 – werden Operationen, wie replace, add oder delete, auf JSON-Objekten möglich. Als kleines Schmankerl für Java-8-Liebhaber ist zusätzlich geplant, Lambda Expressions in JSON Queries zu erlauben.

Eine weitere wichtige Neuerung im Web-Umfeld von Java EE 8 stellt die geplante Unterstützung des HTML5-Standards Server-side Events, also des Server-to-Client Streamings mittels Mime-Type text/event-stream, dar. Dieser Mechanismus macht immer dann Sinn, wenn – nach einmaligem Aufbau einer Verbindung durch den Client – der Server regelmäßig Daten an den Client sendet, wie es zum Beispiel bei einem Stock-Ticker oder einem Dashboard der Fall ist. Laut DeMichiel gab es innerhalb der Spezifikationsgruppe einige Diskussionen über die Art der Umsetzung. Am Ende wurde man sich aber einig, dass eine Umsetzung als Aufsatz auf JAX-RS sinnvoll ist, da dies mit wenig Aufwand realisiert werden kann. Auf Seiten des Servers muss lediglich eine Ressource-Methode so annotiert werden, dass sie den entsprechenden Mime-Type produziert. Auf Seiten des Clients dagegen sorgt ein spezieller Event Listener dafür, dass eingehende Messages verarbeitet werden können.

Was erwartet uns noch Neues im Web-Umfeld? Ach ja, das Action-basierte MVC Framework MVC 1.0! Mittlerweile steht für dieses API der 2nd Early Draft zur Verfügung und kann somit von jedermann begutachtet werden. Viel mehr gibt es an dieser Stelle auch gar nicht zu dem Thema zu sagen, da auf JAXenter bereits zahlreiche Artikel dazu erschienen sind (z.B. https://jaxenter.de/mvc-1-0-early-draft-review-phase-18037). Ich wünschte nur, man würde sich nicht darauf versteifen, neben Facelets auch JSPs unterstützen zu wollen. Aber zum Glück kann man die View-Technologie ja durch sinnvoll(er)e Varianten austauschen.

Ease of Development

Neben den vielen Neuerungen im Web-Umfeld soll es natürlich auch wieder etliche Vereinfachungen für die Entwickler geben. Dank Java EE Security API 1.0 wird z.B. zukünftig eine Autorisation mittels CDI Interceptor möglich werden. Und JMS 2.1 soll eine verbesserte JMS-MDB-Unterstützung (Message Driven Beans) mit sich bringen, um so leichter mit asynchronen Messages umgehen zu können. Mit ganz viel Glück wird zusätzlich eine CDI basierte Variante zur Verarbeitung asynchroner Messages mit in die Spezifikation einfließen. Dies sei aber zum derzeitigen Zeitpunkt noch rein spekulativ, so DeMichiel. Ebenfalls zur Vereinfachung soll das Pruning, also der optionale Wegfall einiger „historischer“ APIs beitragen. Kandidaten sind CORBA sowie EJB 2.x Remote View und Client View. Eine Live-Umfrage während der Session ergab eine 100%ige Zustimmung der Anwesenden für diesen Schritt, was selbst DeMichiel überraschte. Wahrscheinlich haben die wenigen verbliebenen EJB-2.x-Anhänger soviel mit ihrer Programmierung zu tun, dass sie keine Zeit finden, an der JavaOne teilzunehmen.

Ready for the (Cloud) Future?

Bei aller Euphorie über die vielen Neuerungen und Änderungen in Java EE stellt sich natürlich die berechtigte Frage, ob Java EE auch weiterhin eine so wichtige Rolle im Enterprise Computing spielen kann und wird, wie in den letzten Jahren. Mit dem stark modifizierten Management API und einigen neuen Features in Java EE Security 1.0 (z.B. Password Aliasing, User Management, Role Mapping, REST Authentication) versucht man zumindest, aus rein technologischer Sicht Schritt zu halten. Aber reicht das am Ende aus? Genau diese Frage stellte sich auch Ian Robinson, WebSphere Foundation Chief Architect, in seiner Session mit dem passenden Titel „Is Enterprise Java still relevant or Elephant?“.

Laut Robinson brechen die gewohnten Plattformgrenzen mit der Cloud langsam (oder eher schnell?) aber sicher auf. An ihre Stelle treten stattdessen Virtualisierungs-Container. Natürlich spricht theoretisch erst einmal nichts dagegen, auch eine Java-EE-Anwendung in einem solchen Container ablaufen zu lassen. Wenn man aber einmal die Motivation für den Einsatz eines solchen Containers hinterfragt, dann wird schnell klar, dass man einen Container darum wählt, weil er genau das tut, was man möchte – nicht mehr und nicht weniger. Das klingt erst einmal nicht nach einer Spielwiese für Java EE. Ziel muss es also sein, die benötigten Java-EE-Komponenten so bundeln zu können, dass etablierte Technologien genutzt werden können, ohne dabei unnötigen Overhead zu erzeugen. Wie das gehen kann, macht uns bereits seit einiger Zeit das Spring-Boot-Projekt erfolgreich vor. Und auch Java EE hat mit Wildfly Swarm und Dropwizard erste Kandidaten, die in die richtige Richtung gehen.

Java EE steht laut Robinson am Scheideweg. „Java EE is still strong and relevant at the cloud party, but younger guests are making more noise. So let’s make more noise ourselves!“, lautete daher auch sein Schlussplädoyer. Dem kann ich mich nur anschließen!

In diesem Sinne: Stay tuned …

Lesen Sie auch: JavaOne Tagebuch – Tag 0

Verwandte Themen:

Geschrieben von
Lars Röwekamp
Lars Röwekamp
Lars Röwekamp ist Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise und Mobile Computing, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen. Lars Röwekamp, Autor mehrerer Fachartikel und -bücher, beschäftigt sich seit der Geburtsstunde von Java mit dieser Programmiersprache, wobei er einen Großteil seiner praktischen Erfahrungen im Rahmen großer internationaler Projekte sammeln konnte.
Kommentare

Schreibe einen Kommentar

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