Seite 2: Reduktion

Inhaltsverzeichnis

Weniger ist mehr

Die Version 6 führt die Ansätze und Ideen von Java EE 5 konsequent weiter. Getreu dem Motto "weniger ist mehr" setzt die Spezifikation verstärkt auf ein metadatengetriebenes Entwicklungsmodell mit sinnvollem Default-Verhalten. Statt jegliche Details wie in Zeiten von J2EE 1.4 grundsätzlich durch Klassen beziehungsweise Interfaces und deklarativ in XML-Dateien beschreiben zu müssen, kommt man heute mit wenigen Metadaten in Form von Java-Annotationen aus. In der Regel versieht der Entwickler dazu Klassen oder Interfaces mit einfachen Annotationen. Die Bereitstellung des sinnvollen grundsätzlichen Verhaltens ist anschließend die Aufgabe der Laufzeitumgebung, genannt Java EE Container.

Folgendes Beispiel verdeutlicht das metadatengetriebene Modell. Setzt man ein Java Servlet, das sich mit Deployment in einen Java EE Web Container automatisch unter der URL http://{server}/{context}/foo ansprechen lässt, gemäß Java EE 6 um, reicht die Angabe einer einfachen Java-Annotation im Servlet. Eine zusätzliche Konfiguration in XML-Deskriptoren entfällt.

@WebServlet("/foo")
public class Simple30Servlet extends HttpServlet {
 ...
}

Weichen nun die Anforderungen vom vordefinierten Verhalten der Plattform ab, lassen sich die Abweichungen relativ leicht mit zusätzlichen Eigenschaften einer Annotation, durch weitere Annotationen oder alternativ in XML beschreiben. Das folgende Code-Fragment aktiviert die asynchrone Kommunikation für ein HTTPServlet.

@WebServlet("/foo", asynchSupported=true)
public class Simple30Servlet extends HttpServlet {
 ...
}

Zugegebenermaßen hat sich dieses Entwicklungsmodell in vielen anderen Plattformen unter dem Stichwort "Convention over Code" längst etabliert. Umso erfreulicher ist es, das das Muster nun das grundsätzliche Paradigma der Java EE ist. Die wesentlichen Neuerungen der metadatengetriebenen Entwicklungen beleuchtet der zweite Teil der Artikelserie.

Häppchenweise Entwicklerkost

Jedoch scheint die Verwendung von Metadaten nur einen Teil der Komplexität der Plattform zu verringern. Was bleibt, ist weiterhin die Tatsache, dass 30 Spezifikationen auf mehreren tausend Seiten unzählige Vorgaben, Designmuster und APIs definieren. Vergleicht man daher Java EE mit anderen Techniken wie Spring oder Ruby on Rails, scheint fraglich, wie Enterprise-Java die eingangs versprochene Reduktion von Komplexität und Kosten der Entwicklung jemals einhalten will.

Die Expertenkommission hat das Problem erkannt und versucht durch sogenannte Java EE Profiles und durch Pruning sich des Themas anzunehmen. Mit den Profiles kann Java EE 6 ausgehend von einem Basisprofil unterschiedliche Techniken zu einer Konfiguration zusammenstellen. Die Untermengen an Techniken definieren den Rahmen der Laufzeitumgebung, in dem sich ein Anwendungsentwickler bewegen muss.

Das Basisprofil umfasst laut Spezifikation unterschiedliche Lebenszyklus-Annotationen, die Java Transaction API (JTA) und einen kleinen Teilbereich des Java Naming und Directory Interfaces (JNDI). Darüber hinaus definiert die Spezifikation keine Java EE Profiles. Vielmehr sollen Profile außerhalb von ihr entstehen. Ein Beispiel dafür ist das Java EE Web Profile, das parallel mit der "Java EE 6"-Spezifikation erscheint. Weitere Ideen wären Portlet Profile oder Telco Profile, die zurzeit im Gespräch sind. Die weitergehende Betrachtung der Java EE Profiles und des Java EE Web Profile inklusive der Beziehung zu einem Konzept namens EJB Lite erfolgt im dritten Teil der Artikelserie.

Vorbereitung zum Frühjahrsputz

Im Verlauf der "Java EE"-Weiterentwicklung haben die Experten die Spezifikation der Plattform kontinuierlich ergänzt und erweitert. Gleichzeitig stellte jede Release sicher, abwärtskompatibel zu sein. Als Konsequenz trägt sie heute Ballast mit sich, der im praktischen Einsatz keine oder nur noch eine geringe Relevanz besitzt. Wie von einem industriellen Standardisierungsprozess nicht anders zu erwarten, werden mit Java EE 6 nicht einfach Techniken und Funktionen gestrichen. Stattdessen schafft die neue Version mit dem Pruning die Möglichkeit, Funktionen der Plattform in einem zweistufigen Prozess zu entfernen.

In der ersten Stufe sind zu beseitigende Funktionen zu identifizieren und durch die Expertenkommission in einer Java EE Release N aufzunehmen. Die Streichung der Komponenten erfolgt jedoch erst in der zweiten Stufe mit der Release N+1. Zu den Kandidaten zählt aktuell die Container Managed Persistence der Enterprise JavaBeans (EJB). Weitere wie JAX-RPC sind nicht auszuschließen.