Suche
Kolumne: EnterpriseTales

Was erwartet uns in Java EE 8?

Lars Röwekamp, Arne Limburg
Enterprise_Tales_500x375

Kaum haben wir uns an die neuen Features von Java EE 7 gewöhnt, ist auch schon die nächste Version des Java-Enterprise-Standards am Horizont sichtbar. Pünktlich zur JavaOne 2014 wurde der zu Java EE 8 gehörende JSR 366 vom Java EE Executive Committee (EC) einstimmig angenommen. Grund genug, einmal zu schauen, was uns zum geplanten Releasetermin in Q3 2016 so alles erwartet.

„The main focus of this release is on support for HTML5 and the emerging HTTP 2.0 standard; enhanced simplification and managed bean integration; and improved infrastructure for applications running in the cloud.“, heißt es da etwas abstrakt zu der allgemeinen Zielsetzung des JSR 366. Konkreter wird es, wenn man sich die einzelnen Teilziele von Java EE 8 anschaut:

  • Unterstützung neuester Webstandards
  • Weitere Vereinfachung des Programmiermodells
  • Infrastruktur für Cloud-Support
  • Alignment mit Java SE 8

Unterstützung neuester Webstandards

Dass Java EE mit der Zeit geht und versucht, die Neuerungen bzw. Änderungen am Markt zu adaptieren, wird insbesondere im Webumfeld deutlich. So soll die kommende EE-Version nicht nur die in Java EE 7 eingeführte Unterstützung für HTML5 durch die Hinzunahme von Server-sent Events (SSE) erweitern, sondern zusätzlich auch das aufkommende HTTP-2.0-Protokoll innerhalb der Servlet-4.0-Spezifikation unterstützen. Parallel dazu soll es Anpassungen an bestehenden APIs wie WebSocket und JSON Processing geben, alles mit dem Ziel, die Umsetzung moderner, „HTML5 and Friends“-basierter Webanwendungen weiter zu vereinfachen.

Neben der Erweiterung bestehender APIs wird es natürlich auch einige neue Spezifikationen geben. So zum Beispiel das JSON-Binding-API, mit dessen Hilfe auf einen standardisierten Mechanismus zur Übersetzung von JSON- zu Java-Objekten – und vice versa – zurückgegriffen werden kann. Spannend dürfte sicherlich auch die Hinzunahme einer Spezifikation namens MVC 1.0 werden, da mit diesem Action-based Webframework ein direkter Konkurrent zu JSF 2.x ins Java-EE-Lager aufgenommen wird. Kein Wunder also, dass die Geister sich bereits heute über Sinn und Unsinn des Frameworks scheiden (siehe dazu auch der Artikel „Java EE 8 meets MVC: ein Blick in die Kristallkugel“ im Java Magazin 12.2014). MVC 1.0 soll übrigens sowohl losgelöst als auch innerhalb von JSF genutzt werden können.

Weitere Vereinfachung des Programmiermodells

Und auch das Aufräumen innerhalb der Spezifikationen – aka „Specification Alignment“ – geht weiter. Die EE Expert Group möchte, wie schon in Java EE 7 anhand der @Transactional-Annotation gezeigt, weg von technologiebedingten Features hin zu allgemeinen Programmierparadigmen. Konkrete Kandidaten hierfür sind die deklarative Security und die @Schedule-Annotation aus der EJB-Spezifikation. Beide Features sollen zukünftig via CDI auch normalen POJOs zur Verfügung stehen.

Der EE 8 Specification Request stellt in diesem Kontext übrigens bewusst die Zukunft der EJB-Technologie in Frage und geht davon aus, dass die Antwort aus der Community kommen wird: „Now, would this make the EJB programming model obsolete? Only time and developers will tell“. Natürlich bieten EJBs auch weiterhin Features, wie Remoting, Concurrency oder Pooling, die es bisher so im Java EE Stack für keine andere Technologie gibt. Allerdings würde theoretisch nichts dagegen sprechen, auch diese Features zu extrahieren und auf POJOs auszudehnen. Die verschiedenen EJB-Typen könnten dann aus CDI-Sicht als spezielle Stereotypen angesehen werden. Man darf auf die Diskussionen zu diesem Thema innerhalb der kommenden Monate gespannt sein.

Das Aufräumen macht übrigens auch vor historischen Relikten keinen Halt. So sollen z. B. Teile der EJB-2-APIs und CORBA-IIOP-Interoperabilität als „pruned“ markiert werden, was den EE-Serverherstellern zukünftig die Wahl lässt, ob sie diese Features weiterhin unterstützen möchten oder eben nicht.

Infrastruktur für Cloud-Support

Und ewig grüßt das Murmeltier! Wie schon Java EE 7 schreibt sich auch die kommende Version das Hype-Wort „Cloud“ in fetten Lettern auf die Fahne. Innerhalb des JSRs ist u. a. von einer Konfigurationsschnittstelle, Mandantenfähigkeit und vereinfachter Security die Rede. Darüber hinaus soll es standardisierte, REST-basierte APIs zum Management und Monitoring geben, welche es erlauben, portable, serverübergreifende Kunden-/Mandanten-Dashboards zu bauen. Klingt bisher alles noch ein wenig vage. Verzichten wollte oder konnte man innerhalb des JSRs aber sicherlich nicht auf das Hype-Thema, schaut man sich einmal an, was Oracle gerade an Cloud-Strategie auf der diesjährigen Hauskonferenz Oracle OpenWorld in San Francisco verkündet hat.

Alignment mit Java SE 8

Neben den bereits oben angesprochenen Aufräumarbeiten in den einzelnen Java EE JSRs soll es auch eine Anpassung der verschiedenen Java-EE-APIs an Java SE 8 geben. Neue Java-8-Konstrukte, wie wiederholbare Annotationen, Lambda Expressions oder das Date and Time API, sollen dabei ebenso berücksichtigt werden wie die neuen Type Annotations oder CompletableFutures. So wird es zum Beispiel zukünftig nicht mehr notwendig sein, mehrfach auftretende Annotationen in einer „Wrapper“-Annotation zu kapseln. Annotationen wie @NamedQueries oder @Schedules könnten entsprechend als „deprecated“ markiert werden. Die Unified Expression Language wird Lamda Expressions verstehen, und JPA und andere APIs werden von den Vorzügen des Date and Time API profitieren.

Fazit

Alles in allem machen die geplanten Änderungen und Neuerungen von Java EE 8 einen guten Eindruck. Auch wenn auf den ersten Blick scheinbar keine wirklichen Sensationen zu erwarten sind – MVC 1.0 einmal ausgenommen –, deuten die verschiedenen Anmerkungen innerhalb des JSRs 366 bereits in dieser frühen Phase darauf hin, dass die Java-EE-APIs noch stärker aufeinander abgestimmt werden, man zukünftig durchaus gewillt ist, auf politische Ränkespiele zu verzichten und stattdessen von technologiespezifischen Lösungen Abstand zu nehmen. Insbesondere das Auslagern von EJB-spezifischen Features in allgemeingültige CDI-Konstrukte, wie zum Beispiel Interceptors, ist hier ein wichtiges Signal, welches sicherlich noch zu heftigen Diskussionen in der Community führen wird.

In Summe zeigt sich, dass man in der Java EE Expert Group auch weiterhin gewillt zu sein scheint, direktes Feedback der Community aufzunehmen und in neue API-Versionen einfließen zu lassen. Wie sich die Älteren unter uns sicherlich noch erinnern, war dies leider nicht immer der Fall – EJB 1.x lässt grüßen. In diesem Sinne: Stay tuned!

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.
Arne Limburg
Arne Limburg
Arne Limburg ist Softwarearchitekt bei der open knowledge GmbH in Oldenburg. Er verfügt über langjährige Erfahrung als Entwickler, Architekt und Consultant im Java-Umfeld und ist auch seit der ersten Stunde im Android-Umfeld aktiv.
Kommentare

Hinterlasse eine Antwort

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