Convention over Code in Java EE
Mit Java EE 5 gelang ein erster wichtiger Befreiungsschlag in Richtung vereinfachter Anwendungsentwicklung mit wegweisenden Konsequenzen. Java EE 6 behauptet, den seinerzeit eingeschlagenen Weg konsequent weiterzuverfolgen.
- Lars Röwekamp
- Jens Schumann
- Alexander Neumann
Auch wenn es sich die Java-Community lange nicht eingestehen wollte, wurde spätestens mit J2EE 1.4 klar, das essenzielle Bereiche der Enterprise-Java-Plattform eine Sackgasse darstellten. Statt vereinfachter Anwendungsentwicklung und damit Fokussierung auf die Geschäftsprozesse standen Infrastrukturprogrammierung und Verstöße gegen das DRY-Prinzip im Vordergrund. Glücklicherweise gelang mit Java EE 5 ein erster wichtiger Befreiungsschlag mit richtungweisenden Konsequenzen. Java EE 6 behauptet nun, den seinerzeit eingeschlagenen Weg konsequent weiterzuverfolgen. Wohin er führt, zeigt heise Developer in diesem Artikel.
Quo vadis Java EE 6?
- Über den Stand der Dinge im "Java EE 6"-Umfeld
- Convention over Code in Java EE
- Java EE Profiles beziehungsweise "Java EE light"
- Java Web Services: JAX WS und REST API
- App Server Extensibility: Server-Erweiterungen leicht gemacht
- Java EE Blueprints revisited: Die passende Architektur für die neuen APIs
Es gab einmal eine Zeit, in der die Umsetzung einer neuen Business-Methode Arbeiten in mindestens zwei Interfaces, einer Klasse und ein bis zwei XML-Deployment-Deskriptoren erforderte. Damals, als Infrastruktur-Pattern wie Service Locator, Transfer Object und Business Facade zum täglichen Brot eines Enterprise-Java-Entwicklers gehörten, bestand ein Großteil der Entwicklungsaufgaben aus stumpfer Wiederholung technischer Details.
Die gelebte Antwort auf die offensichtlichen Verstöße gegen "Don't repeat yourself" – auch DRY genannt – waren Fleißarbeit beziehungsweise Code-Generierung im Rahmen des Build-Prozesses. Die eigentliche Aufgabe vieler Entwickler, nämlich die Umsetzung geschäftsprozessrelevanter Business-Logik, blieb im Wesentlichen ein Nebenkriegsschauplatz einer J2EE-1.x-Anwendung.
Es ist schon erstaunlich, wie lange die Enterprise-Java-Community in dem Zustand verweilte. Doch dank des tatkräftigen Engagements einiger Open-Source-Protagonisten, vor allem aus dem Umfeld der Frameworks Spring und Hibernate, kam mit Java EE 5.0 viel Bewegung in das Enterprise-Lager.
Enterprise Java – driven by Open Source
Im Ergebnis glänzte die fünfte Version der "Java EE"-Spezifikation durch viele "leichtgewichtige" Ideen, die in ähnlicher oder identischer Form zum damaligen Zeitpunkt längst ihren praktischen Nutzen bewiesen hatten: Die Rückbesinnung auf Java-Basics ergänzt um Metadaten statt XML (POJOs alias Plain Old Java Objects plus Annotationen), die Nutzung eines impliziten Abhängigkeitsmanagements zwischen Komponenten (Dependency Injection beziehungsweise Inversion of Control) und die Einführung eines "Java SE"-Persistenzframeworks (Java Persistence API), das den Funktionsumfang der Container Management Persistence um ein Vielfaches überragte. Insgesamt bedeutete Java EE 5.0 den Wechsel hin zu einem einfacheren Programmiermodell, dass mit sinnvollem Default-Verhalten die Fleißarbeiten eines Entwicklers auf ein erträgliches Maß reduziert und nur bei Abweichungen von ihm zusätzlichen Java-Code erfordert.
Konsequenterweise verabschiedete sich Java EE 5.0 vom bis dato gelebten "remote first"-Ansatz, der die clusterfähige und hochverfügbare komponentenorientierte Anwendungsentwicklung stark in den Mittelpunkt stellte. Die Erfahrungen zeigten, dass die damit verbundene Komplexität den potenziellen Nutzen nur selten rechtfertigt, zumal ein Großteil an "Java EE"-Anwendungen ohne Remoting, Clustering und Fail-over auf Komponentenebene auskommen. Natürlich bleibt es weiterhin möglich, ausgewählte Komponenten oder vollständige Anwendungen hochverfügbar abzubilden. In diesen Fällen – so propagiert es Java EE 5.0 analog zu etablierten Frameworks aus dem Open-Source-Umfeld – erfolgt die Entscheidung bewusst an architektonisch sinnvoller Stelle und nicht wie vorher durch Vorgaben der Plattform und der gelebten Design Pattern.
Es wäre vermessen zu behaupten, dass Java EE 5.0 mit dem Paradigmenwechsel alle Problembereiche der Enterprise-Java-Plattform behoben hätte. Im Gegenteil: In ihr befinden sich weiterhin viele weiße Flecken und einige Kompromisse, die es in späteren Versionen unbedingt zu beheben gilt. So ist es nicht überraschend, dass Java EE 6.0 sich anschickt, genau das zu tun.
