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.
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.
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:
@Entitypublic class ApplicationProperty{@Idprivate 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.
