Enterprise Tales

Was erwartet uns in Java EE 8?

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.

Java EE 8 meets MVC: ein Blick in die Kristallkugel

Für viele überraschend hat Oracle für Java EE 8 einen neuen Java Specification Request zur Ergänzung des aktuellen Web-Development-Stacks angekündigt: MVC 1.0. Obwohl bisher kaum Details zum neuen API bekannt wurden, spaltet der JSR 371 schon jetzt die Community. Grund genug, einen Blick hinter die Kulissen zu wagen.

Multi-Browser-Tab-Support in Java EE 7

Webentwickler kennen das Problem. Bei der Umsetzung bestimmter Use Cases (z. B. Wizards) ist es notwendig, Daten über mehrere Requests hinweg vorzuhalten. Vor Java EE 6 gab es da nur die Möglichkeit, die Daten @SessionScoped abzulegen. Wenn aber der Benutzer die Webanwendung in zwei oder mehr Browsertabs oder -Fenstern verwendet, werden diese Daten zwischen beiden Tabs oder Fenstern geteilt, was meist zu unerwünschten Effekten führt. Der mit JSF 2.0 neu hinzugekommene View Scope (den es seit JSF 2.2 auch als CDI Scope gibt) löst das Problem, solange man sich auf einer XHTML-Seite befindet. Möchte man aber Daten (innerhalb eines Tabs) über mehrere Seiten hinweg behalten und dabei nicht auf Multi-Browser-Tab-Support verzichten, muss man zu anderen Mitteln greifen. Wir werden in dieser Kolumne betrachten, welche Möglichkeiten es da gibt und worauf man dabei achten muss.

Java-EE-Architekturen und JPA: Verwendung des EntityManager im Java-EE-Stack

In der letzten ET-Kolumne haben wir gelernt, wie man mittels JPA Use-Case-bezogen Daten laden kann – oder das Laden bewusst unterdrückt. Das Zauberwort hier heißt „Lazy Loading“. Neben den bereits in JPA 2.0 vorhandenen Möglichkeiten sind wir dabei auch auf das in JPA 2.1 kommende Feature der Fetch bzw. Load Graphs eingegangen. Heute wollen wir einen Schritt weiter gehen und analysieren, wie verschiedene Architekturen den Umgang mit Lazy Loading beeinflussen können und welche Möglichkeiten es im Umkehrschluss gibt, Lazy Loading im gesamten Applikationsstack zu berücksichtigen und sinnvoll verwendbar zu machen.

Was du später kannst besorgen: Lazy Loading in JPA 2.1

In der letzten Kolumne haben wir einen Blick über den Java-EE-Standard-Tellerrand hinaus geworfen und das alternative Query-API „QueryDSL“ vorgestellt. Heute kehren wir wieder zurück in den JPA-Standard. Dort gibt es seit dem 22.05.2013 das „Final Release“ der Version 2.1. Und dieses bringt ein interessantes neues Feature im Bereich Lazy Loading mit sich. Bei diesem neuen JPA-Feature geht es darum, Daten erst zu einem späteren Zeitpunkt zu „besorgen“, nämlich dann, wenn sie tatsächlich gebraucht werden. Dass dieses Feature auch seine Tücken hat und welche Neuerung JPA 2.1 hier bringt, wollen wir im Folgenden zeigen.

Wie frag’ ich die Datenbank? Typsichere dynamische Abfragen mit JPA

Die Java Persistence Query Language (JPQL) ist sehr gut geeignet, statische Abfragen, die schon zur Entwicklungszeit feststehen, zu formulieren, sodass der Persistenz-Provider daraus SQL-Abfragen generieren kann. Wie sieht es aber in Situationen aus, in denen sich die Abfrage in Abhängigkeit von Laufzeitbedingungen ändert? Welche Möglichkeiten gibt es, dynamische JPA-Abfragen zu formulieren und dennoch bereits in der IDE und zur Compile-Zeit sicher zu sein, keinen Syntaxfehler eingebaut zu haben? Jeder kennt wohl den Use Case: Es gibt eine Suchmaske mit mehreren Feldern, z. B. „Vorname“ und „Nachname“. Gesucht werden soll die zugehörige Person. Eine Abfrage gegen die Datenbank muss man in Abhängigkeit davon absetzen, ob eines der Felder befüllt ist oder es beide sind. Wie kann man einen solchen Use Case mit JPA umsetzen, ohne auf Typsicherheit zu verzichten?

Enterprise Tales: Schnell, schneller, JUEL

Webanwendungen auf Basis von JavaServer Faces stehen nicht selten in dem Ruf, unnötig langsam zu sein. Als Ursache sind schnell der komplexe Lifecycle sowie der damit einhergehende Stateful-Ansatz ausgemacht. Bei genauer Betrachtung stellt sich allerdings häufig heraus, dass die klassischen Performance-Leaks an ganz anderer Stelle zu finden sind. Das JSF-Framework gilt bei Kritikern (insbesondere bei denen, die sich nicht die Mühe gemacht haben, sich intensiv damit zu beschäftigen) als schwerfällig und „oversized“. Grund hierfür ist vor allem der 6-Phasen-Lifecycle sowie der im Hintergrund verwaltete Komponenten-State. Gerne wird dabei vergessen, dass mit der Version 2.0 gleich eine ganze Reihe sinnvoller Änderungen [1] in die Spezifikation eingeflossen ist, die sich genau dieser Thematik annehmen. Wieso also nach wir vor diese Kritik?

Enterprise Tales: Apache TomEE

Passend zur JavaOne 2011 war er da, der erste offizielle JavaEE-Web-Profile-Container der Apache Software Foundation, kurz Apache TomEE. Sichtlich erleichtert gab Projektleiter David Blevins (IBM) bekannt, dass der „neue“ Server das TCK bestanden hat. Doch was genau steckt hinter dem Apache-TomEE-Container?

Enterprise Tales: Welcome to the Jungle

Was waren das noch für Zeiten, als aus Mangel an Alternativen die Wahl des richtigen Enterprise Java Frameworks zur reinen Formsache verkam. Um 2000 herum hieß die einzig akzeptable Lösung, dank „einfach“ zu nutzender APIs und standardisierter Server, J2EE. Wenige Jahre später war das Spring Framework das Maß aller Dinge. Heute dagegen sieht die Enterprise-Java-Welt schon anders aus – Welcome to the Jungle!