Was lange währt…

Java EE 6 auf einen Blick

Dirk Weil

Am 10. Dezember 2009 war es endlich soweit: Die lange erwartete finale Version 6 der Java-EE-Spezifikation wurde freigegeben. Mit 3½ Jahren seit dem Release der Vorversion hat man sich diesmal wieder recht lange Zeit gelassen. Hat sich das Warten gelohnt?

Die Java EE – früher J2EE – ist in den Köpfen vieler Entwickler in Ungnade gefallen. Insbesondere die Geschäftslogikanteile EJB und Persistenz waren in den älteren Versionen tatsächlich viel zu aufwändig zu benutzen. Die Abhilfe in Form von Java EE 5 kam nach fast vier Jahren viel zu spät, was einen guten Nährboden für Alternativframeworks bildete. Die lange Wartezeit hatte allerdings auch ihr Gutes: Viele gute Features bspw. aus Spring sind in die aktuelle Spezifikation eingeflossen. Sie hat nun einen sehr hohen Reifegrad erreicht, so dass der Umfang für die meisten Aufgaben mehr als ausreichend ist. Entwickeln mit den ‚Basics‘ macht wieder Spaß.

Eine Spezifikation von Spezifikationen

Rufen wir uns noch mal kurz ins Gedächtnis, was die Java EE eigentlich ist: Diese ‚Dach-Spezifikation‘ umklammert gut drei Dutzend einzelne Spezifikationen für unterschiedlichste Bereiche der Anwendungsentwicklung mit Java. Im Kern zielt sie auf gemanagte Umgebungen, d. h. Anwendungen, die in einem Applikationsserver laufen. Es sind allerdings auch viele Teilspezifikationen darunter, die außerhalb eines Servers verwendet werden können, was auch ein Ausdruck der zunehmenden Leichtgewichtigkeit der Java EE ist. Dieser Artikel kann nicht die gesamte Plattform umfassen, erst recht nicht auf alle Neuerungen im Detail eingehen. Beschränken wir uns also für’s Erste auf die Highlights im klassischen (Web-)Anwendungs-Stack.

Abb. 1: Java-EE-Anwendungs-Stack

Die Anwendungsaufteilung in diesem Stack ist trivial: Die Geschäftslogik wird in Form von Enterprise JavaBeans (EJBs) programmiert, wobei die nahezu immer notwendigen Datenbankzugriffe mittels Java Persistence API (JPA) erfolgen. Soll die Anwendung eine Web-Oberfläche besitzen, sind dafür JavaServer Faces (JSF) Mittel der Wahl, die technisch im Servlet-Container ablaufen.

[ header = Seite 2: Daten an der Basis ]

Daten an der Basis

Fangen wir mal unten an, an der Datenbank. Die ist in aller Regel relational. Da wir objektorientiert zugreifen wollen, kommen O/R-Mapper wie Hibernate oder EclipseLink ins Spiel. Seit Java EE 5 ist für deren Nutzung das Abstraktionslayer JPA im Standard vorhanden. Wie in fast allen Bereichen der Java EE begegnen uns hier einfache Java-Objekte, die mittels Annotationen (oder alternativem XML) um Persistenz-Metadaten angereichert sind:

@Entity
public class ApplicationProperty
{
@Id
private String id;
private String value;
…
}

Fehlende Angaben – im Beispiel Tabellen- und Spaltennamen – werden per Convention over Configuration mit sinnvollen Defaults besetzt. Diese einfachen Objekte können dann mit Hilfe des sog. Entitymanagers in die Datenbank gespeichert bzw. von dort gelesen werden:

ApplicationProperty aprop = …;
entityManager.persist(aprop);

Objektstrukturen wie Relationen oder Ableitungshierarchien können mit JPA problemlos abgebildet werden. Für Suchanfragen existiert eine SQL-ähnliche, relationsübergreifende Abfragesprache. Die Integration von JPA 1.0 in die Java EE 5 war zweifellos ein bahnbrechender Fortschritt, was die überwiegend positive Resonanz der Entwicklergemeinde zeigte. JPA 2.0 schließt nun viele verbliebene Lücken und kommt in seinem Umfang mit proprietären O/R-Mappern gleich auf.

Die Neuerungen sind recht zahlreich, so dass hier nur einige angesprochen werden können. Eine wesentliche Ergänzung sind die Criteria Queries, mit denen es möglich ist, dynamische Suchabfragen strukturiert, API-gestützt zu erzeugen. Ein lästiges Problem beseitigt das sog. Orphan Removal. Hiermit wird die Abbildung abhängiger Objekte über 1:n- oder n:m-Relationen möglich, wobei abhängige Einträge automatisch gelöscht werden, wenn sie nicht mehr referenziert werden. Ein weiteres Ärgernis war, dass in einer Entity-ID (d. h. im Primärschlüssel) keine Referenzen zu anderen Entities verwendet werden konnten. Dies ist mit JPA 2.0 nun möglich.

Leichte Bohnen

Enterprise JavaBeans haftet der Malus an, starr, kompliziert und aufwändig zu sein. Diese Einschätzung stammt aus den Zeiten bis EJB 2.x, in denen die Kritik tatsächlich berechtigt war. Und wenn der Ruf einmal zerstört ist … Vielleicht wäre es angeraten, EJBs ab der Version 3.x einen anderen Namen zu geben, um sie von den psychologischen Altlasten zu befreien. EJBs der aktuellen Spezifikation sind nämlich alles andere als kompliziert oder schwergewichtig.

// SomeServiceBean.java
@Stateless
public class SomeServiceBean implements SomeService
{
@Override
public void doSomething(String s)
{
…
}
}

// SomeService.java
@Remote
public interface SomeService
{
public void doSomething(String s);
}

Der Code-Ausschnitt zeigt eine Stateless Session Bean mit einem Remote-Interface für den Zugriff aus einem Client. Kein XML-Descriptor, keine technischen Interfaces, keine technischen Exceptions wie in der Version 2.x – einfacher geht es kaum.

EJB 3.1 ist „nur“ ein Minor Release, demzufolge sind die Neuerungen nicht revolutionär, aber dennoch vielfältig. Sie komplettieren den Themenbereich und erfüllen teilweise lange gehegte Wünsche. So stellt man beispielsweise in EJB-Projekten häufig fest, dass das im Allgemeinen richtige und wichtige Vorgehen, ‚gegen Interfaces‘ zu programmieren, zu einer 1:1-Entsprechung von EJB-Klassen und Zugriffsinterfaces degeneriert. Zumindest im lokalen Umfeld, d. h. für Zugriffe innerhalb einer JVM, bringen die Zugriffsinterfaces keine Vorteile. Seit EJB 3.1 kann man sie weglassen und damit immerhin 50 % der Programmartefakte einsparen.

Eine weitere Wunscherfüllung ist die Einführung von Singletons. Mit Hilfe der Annotation @Singleton kann eine EJB programmiert werden, von der zur Laufzeit nur eine Instanz erzeugt wird (allerdings pro JVM!). Über weitere Annotationen können der Initialisierungszeitpunkt (Anwendungsstart oder erster Zugriff) und Abhängigkeiten zu weiteren Singletons bestimmt werden.

@Singleton
@Startup
@DependsOn("ApplicationPropertyServiceBean")
public class SystemServiceBean
{
…
}

Die erheblich erweiterten Timer-Möglichkeiten und asynchrone Methoden sind zwei weitere Highlights der Version 3.1.

[ header = Seite 3: Service (nicht nur) für den Browser ]

Service (nicht nur) für den Browser

Als Ansprechpartner für Web-Requests dient der Servlet-Container. Im Hinblick auf die Präsentation einer Benutzeroberfläche werkelt er allerdings eher im Hintergrund und als Basis für Präsentationsframeworks wie JSF, während Servlets bei RESTful-Ansätzen auch direkte Objekte der Begierde sein können. In Servlet 3.0 ist der POJO-Annotationsszug nun auch angekommen:

@Servlet(urlMapping={"/myServlet"})
public class SimpleServlet
{
@GET
public void handleGet(HttpServletRequest req, HttpServletResponse res)
{
…
}
}

Auch hier: Kein XML-Descriptor, keine zu implementierenden Interfaces. Ähnliches gilt auch für Filter und Listener.

Eine nützliche Erweiterung für Framework-Entwickler ist das Servlet Context API. Hierüber ist es u. a. möglich, dynamisch zur Laufzeit Servlet-Registrierungen vorzunehmen oder zu ändern. Interessant ist sicher auch, dass EJBs fortan direkt in die Webanwendung integriert werden können. Statt eines aufwändigen EAR-Files reicht dann ein WAR-File, das die EJBs in seinem classes– bzw. lib-Anteil mitbringt – WAR-Files als ‚EAR Lite‘ sozusagen.

Gesichtspflege

JavaServer Faces liegen jetzt auch in Version 2.0 vor. Über die Neuerungen wurde und wird bereits viel berichtet, sodass ich aus der Vielzahl nur zwei Punkte herausgreifen möchte: Facelets (XHTML) treten an die Stelle der bislang standardmäßig zum Rendern genutzten JavaServer Pages (JSPs). Die Kombination von JSF und JSP hatte sich vielfach als problematisch herausgestellt, so dass diese Weichenstellung absolut notwendig war.

AJAX ist aus modernen Web-Oberflächen nicht wegzudenken. Die Integration in JSF ist auch gut möglich, wie eine große Zahl von JSF-Bibliotheken deutlich macht. Für einen solch zentralen Punkt wäre aber ein direkter AJAX-Support ohne Zusatzbibliotheken wünschenswert. Dieser ist in JSF 2.0 nun verfügbar. Er ebnet hoffentlich auch den Weg zu einer höheren Kompatibilität der Zusatzbibliotheken.

Profil zeigen

Die Java EE 6 verfolgt konsequent den Weg, der bereits mit der Vorversion eingeschlagen wurde. Trotz aller Bemühungen um Vereinfachung ist die Spezifikation aber nicht kürzer geworden – im Gegenteil. Das lässt sich vermutlich in einem Umfeld, das auf Aufwärtskompatibilität achten muss, nicht wirklich vermeiden. Nun benötigt bei weitem nicht jede Anwendung alle 37 Teilspezifikationen. Für eine normale Web-Anwendung reicht da beispielsweise ein gutes Dutzend. Diese Erkenntnis nehmen die neu eingeführten Profile auf. Sie reduzieren den Gesamtumfang auf ein zielorientiertes Subset, das natürlich bei Bedarf erweitert werden kann. So müssen sich Entwickler (und Produkte) nicht mit Dingen herumschlagen, die außerhalb des aktuellen Fokus liegen.

Fazit

Befürworter aber auch Kritiker bescheinigen der Java EE, den richtigen Weg eingeschlagen zu haben. Quer durch die vielen Teilspezifikationen bringt das Konzept der Metadatenversorgung per Annotation in Kombination mit sinnvollen Vorgabewerten eine deutliche Erleichterung. Die vielen Neuerungen zeigen, wie lebendig diese Plattform ist. Der große Funktionsumfang – Segen und Laster zugleich – lässt sich mit passend geschnittenen Profilen in den Griff bekommen. Bleibt zu hoffen, dass die Java EE von Entwicklern und Entscheidern wieder im ursprünglichen Sinne verstanden wird – als umfassende Plattform, auf der effizient Java-Anwendungen im Enterprise-Umfeld erstellt werden können.

Geschrieben von
Dirk Weil
Dirk Weil
  Dirk Weil ist seit 1998 als Berater im Bereich Java tätig. Als Geschäftsführer der GEDOPLAN GmbH in Bielefeld ist er für die Konzeption und Realisierung von Informationssystemen auf Basis von Java EE verantwortlich. Seine langjährige Erfahrung in der Entwicklung anspruchsvoller Unternehmenslösungen machen ihn zu einem kompetenten Ansprechpartner und anerkannten Experten auf dem Gebiet Java EE. Er ist Autor in Fachmagazinen, hält Vorträge und leitet Seminare und Workshops aus einem eigenen Java-Curriculum.
Kommentare

Schreibe einen Kommentar

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