Java EE 6 – Viele Antworten auf alte Fragen

Java EE 5 war schon ein gewaltiger Schritt in die richtige Richtung. Das gesamte Entwicklungsmodell wurde überarbeitet und wesentlich vereinfacht. Ich würde sogar behaupten, dass Java EE seit der Version 5 überhaupt erst sinnvoll benutzbar ist.

Die Änderungen in Java EE 6 sind nicht ganz so umwälzend aber haben in paar wirklich sinnvolle Features dabei, die ich schon seit langem vermisst habe.

EJB 3.1

Besonders interessant finde ich hier die Einführung von Singletons. Das ist enorm praktisch für beispielsweise Konfigurationen. Ok, es wird im wirklichen Leben wieder erschreckend viele Entwickler geben, die es als JCA Ersatz verwenden – aber das ist ein anderes Thema.

Sehr schön jetzt auch die Möglichkeit der parallelen Ausführung. Damit kann ich z.B. drei Webservices gleichzeitig aufrufen und die Methode kehrt zurück, wenn alle abgearbeitet wurden. Somit dauert der Aufruf nur noch so lange wie der langsamste Service und nicht mehr wie die Summe aller Services.

Endlich wird es auch möglich sein, den Timer Service direkt beim Deployment zu aktivieren – ohne den Umweg über ein Hilfsservlet.

Zusätzlich gibt es noch diverse Vereinfachungen und die möglichkeit den Container embedded zu betreiben – extrem sinnvoll für Tests oder für komplexe Desktopapplikationen.

JPA 2.0

Das was die meisten Menschen freuen dürfte ist „Query by Example“ oder wie es hier heißt „CriteriaAPI“. Damit lassen sich Entities mit Hilfe eines Teilwiese gefüllten Beispielobjekts finden. Datenbankabfragen ganz ohne QL.

Weiterhin kommen ein paar nette Erweiterungen für Embedded Objekte hinzu und das Löschen von Orphants wird möglich sein. (Letzteres konnte zwar jeder JPA Provider war aber nicht standartisiert.)

Spanned sehen auch die Erweiterungen zu Plain Type Collections und Validierungen aus.

JSF 2.0, Servlet 3.0 usw.

Im wesentlichen mehr Komponenten, bessere Ajax Integration und Unterstützung für IO Scheduling „Comet“. Zusätzlich eine Integration von Template artigen Views

Die Aussagen sind noch recht vage und Frontend ist auch nicht so ganz mein Fachgebiet. Ich persönlich würde ein Vorantreiben von JavaFX begrüßen, das es im Bereich Frontend prinzipbedingt mehr Optionen bringen dürfte.

Die Wiederentdeckung des Backends

Zwei Tier Architekturen sind hip, ich befürchte, das Wort „hip“ ist es nicht. An allen Enden der Web 2.0 Welt wird mit PHP, RAILS, mitunter auch Java Servlet Technologie gebaut. Ein bisschen Code, der die Seite zusammenhält, ein bisschen DB – klassische zwei Tier Architektur. Warum auch nicht? Es ist schnell gebaut und man spart den Kommunikationsoverhead mit dem Backend.

Dennoch scheint es gute Gründe zu geben, etwas Logik aus dem Frontend zu ziehen. Die einen bauen in ihre Servlet Engine einen Spring Container, die anderen gliedern Funktionalität in WebServices aus, einige tun sogar beides. Nicht selten sind die gleichen Entwickler, die Java früher für fast alles zu langsam empfanden diejenigen, die kein Problem damit haben, heute Ruby wegen der schnelleren Entwicklungszeiten zu bevorzugen – und die gleichen Entwickler, die mit Kommunikationsoverhead gegen EJBs argumentiert haben, heute die, die Services mit SOAP integrieren. Zeiten ändern sich.

Jedenfalls werden die Einschränkungen des zwei Tier Ansatzes spätestens dann deutlich, wenn Funktionalität ausgegliedert werden soll oder asynchrone Verarbeitung benötigt wird.

EJBs haben immernoch einen schlechten Ruf. Die waren bis EJB 2.1 unhandlich und alles andere als einfach zu benutzen. Wie ungeliebt die Technologie ist wird einem klar, wenn man sich Projekte anguckt, die durch Managemententscheidung EJB basiert gebaut wurden: Praktisch jede Firma hat dafür zunächst einmal ein eigenes Framework entwickelt, um die Komplexität des unterliegenden Frameworks vom Entwickler fernzuhalten. Die Erfolge sind zumeist mäßig. Mit der Komplexität wird auch ein größerer Teil der zugrundeliegenden Regeln für die Anwendung der Technologie versteckt, was zu teilweise abenteuerlichen Seiteneffekten führt.

EJB 3 hat mit der Konfigurationsarie, die für klassische EJBs benötigt wurde, aufgeräumt und ist ausgesprochen benutzbar. Es existiert Technologie zur Anwendungsverteilung, mit JPA benutzbare Datenbankabstraktion, Sicherheits- und Transaktionsverwaltung sowie techniken zur timergesteuerten und asynchronen Verarbeitung. Allerdings war man bislang an Java gebunden, um diese Technologie nutzen zu können.

Mit Java EE 6 und der Referenzimplementation Glassfish 3 wird sich das grundlegend ändern. Frontend ist nicht mehr nur Servlet/JSP sonder auch RAILS mit JRuby, PHP oder Python. Dabei laufen die Skriptsprachen in der JVM. Das hat einen ganz wunderbaren Vorteil: Ich kann von meiner PHP Anwendung oder direkt aus meinem Ruby Code EJBs aufrufen. Das hat schon einen gewissen Charme und ist meiner Meinung nach einer der brilliantesten Schachzüge von Sun überhaupt.

Ich kann also meine komplette Rails Applikation in einem Applicationserver zugreifen und habe die ganzen netten Vorteile wie Monitoring, Zugriff auf ein Backend und meine Applikationen laufen in der JVM auch noch schneller als vorher (der Ruby Interpreter ist nicht gerade auf Geschwindigkeit optimiert).

Das beste aus zwei Welten. Das ist ein bisschen wie Weihnachten und Ostern zusammen. Ich denke, dieser Ansatz wird viele Freunde finden.