Ein Ausblick auf die Trends und Herausforderungen, denen sich die Java EE stellen muss

Java EE 6: Wo führt die Reise hin?

Claudia Fröhling

In einer Woche ist es soweit: Das Java Magazin Spezial „Java EE 6“ kommt in den Handel. Es erwarten Sie über 100 Seiten geballtes Java-Enterprise-Wissen. Dieses Interview mit Lars Röwekamp und Jens Schumann von OpenKnowledge soll Ihnen einen ersten Vorgeschmack geben. Viel Spaß!

Java EE hat in den letzten Jahren viel Boden gut gemacht. Wir sehen jetzt vor uns eine neue, aufgeräumte Technologie, in die viel Communityfeedback geflossen und die damit wieder zu einer interessanten Entwicklungsplattform geworden ist. Wie geht es von hier aus weiter? Wie wird sich Java EE auf Herausforderungen wie Cloud Computing und Modularisierung einstellen? Welche Zukunft ist der Dependency Injection beschert und was bedeutet Oracle als neuer Herr im Hause für Java EE 7?

Claudia: Ich denke, als Fazit dieses Hefts können wir festhalten: Java EE 6 ist besser als ihr Ruf. Was sind jetzt die nächsten Schritte, um diesen Ruf zu halten?

Lars: Nachdem Java EE nun seine Hausaufgaben gemacht hat, ist die wichtigste Aufgabe für die verbliebenen Protagonisten, die Java-Entwickler zurück zu gewinnen. Neben konsequenter Lobbyarbeit muss natürlich auch der Nachweis erbracht werden, dass man mit Java EE 6 erfolgreich und effizient Projekte abschließen kann, die am Ende auch noch wartbar sind. Hier ist auch die Unterstützung der Fachpresse notwendig, die sich in der Vergangenheit bei allen technologischen und inhaltlichen Problemen der J2EE-Plattform nicht immer ganz neutral verhalten hat. Ziel muss es sein, den Java-EE-6-Mehrwert klar zu positionieren.

Claudia: Unser Sonderheft ist ja schon mal ein Anfang 😉

Jens: Über den Mehrwert von JPA 2.0 oder JSF 2.0 brauchen wir sicherlich nicht diskutieren. Doch die negative Grundeinstellung zu EJB lässt sich leider nicht so schnell überwinden. In der Vergangenheit ist gerade mit dieser Komponententechnologie viel zu viel schiefgelaufen, als das die negativen Erfahrungen über Nacht aus dem Gedächtnis verschwinden. Vielleicht kann hier CDI einen positiven Beitrag leisten. Denn Vergleichbares bietet keine andere Komponententechnologie.

Ab 12.11.2010 am Kiosk!

Claudia: Eurer Meinung nach kann und sollte man ohne Vorbehalte auf Java EE 6 setzen?

Lars: Auf jeden Fall. Es spricht mittlerweile nichts gegen den Einsatz von Java EE 6, gerade für neue Projekte. Neben den rein technologischen Aspekten darf auch nicht vernachlässigt werden, dass es sich bei Java EE nach wie vor um den Enterprise Java Standard handelt. Ein Mehrwert, der leider häufig viel zu gering bewertet wird. Dank CDI und dem darin definierten CDI-Extension-Mechanismus lässt sich Java EE als führendes Framework verwenden und bei Bedarf nahezu jedes beliebige 3rd-Party-Framework – oder Teile davon – einbinden. Sicherlich ist die Migration bestehender Software zu Java EE 6 nicht unbedingt trivial, speziell der Wechsel von JDBC bzw. EJB 2.x Entity Beans zur Java Persistence API oder von einem x-beliebigen Webframework zu JSF 2.0. Bestehende J2EE-Anwendungen sollten sich jedoch schon einmal an den Gedanken einer Migration zu Java EE 6 gewöhnen.

Claudia: Wo sollte man vorsichtig sein?

Jens: Insgesamt macht Java EE 6 einen runden Eindruck. Trotzdem merkt man, dass die @Inject- und CDI-Spezifikationen relativ spät in Java EE 6 aufgenommen wurden. Als Konsequenz gibt es ein paar unangenehme Überschneidungen, die vermeidbar gewesen wären. Zu den offensichtlichsten Beispielen gehören die Ähnlichkeiten der @Inject-Annotation mit @Resource und @EJB, von @ManagedBean und @Named sowie der Scopes aus JSF 2.0 und CDI. Da meiner Meinung nach die Zukunft in @Inject und CDI liegt, sollte man grundsätzlich auf die @EJB-, @ManagedBean- und die JSF-2.0-Scope-Annotationen verzichten. Man kommt ziemlich gut ohne diese Annotationen aus, ohne sich technologisch Einschränken zu müssen.

Claudia: Welchen Einfluss wird CDI auf die Java-EE-Anwendungsentwicklung haben?

Lars: Interessante Frage. CDI ist mehr oder minder über Nacht in die Java-EE-Spezifikation aufgenommen worden, nicht ganz kritiklos wohlgemerkt. Dennoch halten mit CDI interessante Konzepte Einzug, die nicht nur für Java EE, sondern für die gesamte Anwendungsentwicklung ziemlich neu sind. Dabei kann sich die Architektur einer CDI-Anwendung erheblich von den klassischen Architekturansätzen unterscheiden. Die Differenzen führen zu einer gänzlich anderen Anwendungsentwicklung, die anfänglich sehr fremd wirkt, aber unglaublich elegant ist. CDI geht damit deutlich weiter, als die wenigen Seiten Spezifikation vermuten lassen.

Claudia: Wo zum Beispiel?

Lars: Vor CDI konzentrierte sich Dependency Injection vornehmlich auf das Abhängigkeitsmanagement technischer Infrastruktur. Der Zugriff auf Ressourcen und Dienste stand im Fokus. Mit CDI hält nun das Konzept der fachlichen Dependency Injection Einzug, d. h. die CDI Runtime verwaltet nicht nur technische, sondern auch fachliche Abhängigkeiten. Um zum Beispiel auf den aktuell angemeldeten User zuzugreifen, reicht ein @Current private User user; aus, statt diesen wie bisher manuell via ThreadLocal oder Parameterübergabe über alle Schichten hinweg an die benötigten Codestellen durchzuschleifen. Dabei ist für den Nutzenden uninteressant, wo der aktuelle User technisch vorgehalten wird.

Jens: Darüber hinaus ist das CDI-Event-Modell sehr elegant. Die Umsetzung einer eventbasierten Java-EE-Anwendung, über alle Schichten hinweg, war noch nie einfacher.

Claudia: Ist und bleibt das beherrschbar?

Jens: Das ist sicherlich eine berechtigte Frage. Mit AOP hat man schon vor einigen Jahren die Erfahrung gemacht, dass Technologie zwar sehr elegant sein kann, deren Beherrschbarkeit aber schnell an Grenzen stößt. Die dort aufgetretenen Problemstellungen gelten auch für CDI: Wenn die Laufzeitumgebung nun auch fachliche Objekte bereitstellt und ich als Anwendungsentwickler nicht weiß, woher die Objekte kommen, so verliere ich scheinbar die Kontrolle über meine Software. Alles, was früher direkt in Code sichtbar war, versteckt sich heute hinter ein paar Annotationen. Die Frage, wie die Anwendung zur Laufzeit nun genau funktioniert, lässt sich dadurch kaum beantworten. Rickard Öberg hatte seinerzeit für seine ziemlich ausgereifte AOP-Plattform ein Tool geschrieben, dass die effektive Laufzeitkonfiguration visualisiert. Wir werden wohl bei CDI nicht ohne so etwas auskommen.

Geschrieben von
Claudia Fröhling
Kommentare

Schreibe einen Kommentar

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