"Usability wird ein Kernthema von Java EE 7" - JAXenter

"Usability wird ein Kernthema von Java EE 7"

E. T.: Das hört sich ein wenig danach an, dass Java EE 7 zwar der erste, aber lange noch nicht der letzte Schritt in Richtung Cloud sein wird …

Adam Bien: Das ist absolut richtig. Nehmen wir als Beispiel JAX-RS, also das Java-API für RESTful Web Services. Hier waren die geänderten Anforderungen durch die Cloud zunächst der Leitgedanke für etliche Neuerungen. Am Ende haben wir dann gesagt, dass wir die Cloud zunächst erst einmal in den Hintergrund schieben und uns um verbesserte Usability kümmern werden.

E. T.: Also verbesserte Usability in Java EE 7 quasi als Basis für die Unterstützung der Cloud in Java EE 8?

Adam Bien: Usability oder anders gesagt die zentrale Verbesserung und Vereinheitlichung von nichtfunktionalen Eigenschaften wird sicherlich eines der Kernthemen von Java EE 7 werden, das Ganze natürlich mit dem Fokus, Java EE als „Platform as a Service“ auszubauen. Richtig abgehen wird es mit der Cloud aber erst in Java EE 8, denn dann haben wir Jigsaw – also die Modularisierung aus dem JDK 8 – und erst dann lassen sich auch die Anwendungen richtig modularisieren.

E. T.: Es kommen mit Java EE 7 ja auch neue Themen wie WebSockets inkl. HTML-Support oder ein JSON-API hinzu, um hier nur zwei Beispiele zu nennen. Die Expert Group scheint sich also stark an dem realen Bedarf der Community zu orientieren.

Adam Bien: Das ist richtig. Aber auch scheinbar alte Themen werden wieder aufgegriffen. Es wird zum Beispiel eine standardisierte Caching-Lösung geben und – was mich persönlich besonders freut – JMS wird nach fast zehn Jahren komplett überarbeitet und deutlich vereinfacht bzw. modernisiert werden.

E. T.: Mit Java EE 6 hat beinahe unbemerkt ein alternatives Komponentenmodell Einzug in die Spezifikation gehalten – CDI. Welche Bedeutung misst du CDI für die Zukunft des Enterprise-Java-Standards bei? Könnte es zur Ablösung der EJB-Technologie kommen?

Adam Bien: Das ist sogar unser Ziel. Ich bin an der EJB-3.2-Spezifikation beteiligt und unser Anliegen ist es, die Aspekte von @Stateless und @Stateful, wie zum Beispiel die impliziten Transaktionen, allgemein über eigene Annotationen zugänglich zu machen. Dann werden EJBs optional und man könnte eine CDI Managed Bean einfach mit @Transaction annotieren. Ähnliches sieht man heute schon bei Seam, Caucho CanDI oder Apache MyFaces CODI. Was ich dann natürlich noch bräuchte, wäre etwas wie @MaxPool oder @MaxInstances, um so, wie heute schon recht einfach mit den EJBs möglich, „Denial of Services“-Attacken abzuwehren. Meine Hoffnung ist auch, dass JSF Managed Beans als Deprecated markiert werden. Dann hätten wir nur noch CDI und Annotationen und CDI wäre das Programmiermodell schlechthin.

E. T.: Würde das dann auch implizieren, dass die EJB-Spezifikation mittelfristig verschwindet?
Adam Bien: EJB 3.2 wird es auf jeden Fall noch geben, es wird sogar weiterentwickelt. Ich wäre aber nicht traurig, wenn es danach keine EJB-Spezifikation mehr gibt. EJBs mag historisch gesehen eh keiner. Somit wäre es marketingtechnisch ein genialer Zug. Je mehr man in Java EE 7 und Java EE 8 löscht, desto besser ist es.

E. T.: Also wird CDI in Version 1.1 um Transaktionen und Security erweitert werden, so dass für diese essentiellen Features nicht auf entsprechende CDI Extensions zurückgegriffen werden muss?

Adam Bien: Das ist zumindest der Stand heute. Um ehrlich zu sein, weiß ich gar nicht, ob ich das hier überhaupt sagen darf, aber man kann den aktuellen Stand der Dinge auch auf den öffentlichen Listen nachlesen.

E. T.: CDI ist ja nicht nur ein „neues“ Komponentenmodell, sondern ermöglicht dank des Event-basierten Ansatzes und der Interceptors eine sehr lose Kopplung fachlicher Komponenten jenseits des klassischen Schichtenmodells. Fachliche Injection statt Infrastruktur-Injection ist hier das Schlagwort. Was glaubst du, wie man dieses Paradigma den Leuten näher bringen kann?

Adam Bien: Was ich in Java-EE-Projekten versuche, ist, mich gemeinsam mit den Teammitgliedern ausschließlich auf Fachlichkeit zu konzentrieren. Alles, was speziell Java EE 6 ist, ist dabei zunächst verboten. Erst wenn man merkt, dass man nicht weiterkommt, fängt man an – zum Beispiel via @Inject -, sich die benötigte Fachlichkeit oder Funktionalität dazuzuholen. Dabei gehe ich im Nachgang immer wieder hin und lösche unnötige Annotationen. Generell gilt, dass die Anzahl der verwendeten Annotationen so gering wir irgend möglich gehalten werden sollte – dann ist die Architektur gut. Leider ist in den Köpfen der meisten Entwickler das absolute „Overengineering“ inkl. 20-Schichten-Modell drin, woran sicherlich auch einige meiner Artikel für das Java Magazin aus dem Jahr 2001 schuld sind, in denen ich alle Design-Patterns der Welt in einer einzigen Gästebuch-Anwendung vereint habe. Damals habe ich ebenfalls alles „overengineered“. Seit fünf Jahren versuche ich dagegen, alles zu löschen, was überflüssig ist.

E. T.: Das ist doch ein schöner Schlusssatz, den wir allen Entwicklern ans Herz legen können. In diesem Sinne besten Dank für deine Zeit und deine Ideen, Adam.

Lars Röwekamp ist Geschäftsführer der open knowledge GmbH und berät seit mehr als zehn Jahren Kunden in internationalen Projekten rund um das Thema Enterprise Computing (Twitter: @mobileLarson).

Matthias Weßendorf arbeitet für die Firma Kaazing. Dort beschäftigt er sich mit WebSocket, HTML5 und weiteren Themen rund um das „Next Generation Web“. Matthias blogt regelmäßig auf http://matthiaswessendorf.wordpress.com (Twitter: @mwessendorf).

Kommentare

Schreibe einen Kommentar

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