Das neue Spring der RuhrJug vorgestellt

Eberhard Wolff war als Referent des zweiten Vortragabends der neuen Java User Group im Ruhrgebiet, kurz RuhrJug, geladen. Sein Thema: Spring 3.0, die demnächst zu erwartende größere Release des populären Java-Frameworks. Wie beim Kick-off, über das heise Developer berichtete, fand die Veranstaltung wieder im Essener Unperfekthaus statt.

Frühlingsputz bei Spring 3.0

Eingangs seines Vortrags gab Wolff, der Regional Director und Principal Consultant von SpringSource ist, dem Unternehmen, das hinter dem Spring Framework steht, eine Übersicht der Kern-Features von Spring und der Neuerungen in Version 3.0. Das Hauptaugenmerk der Entwickler liegt jetzt auf der Unterstützung von RESTful (Representational State Transfer) Web Services und der Einiführung einer Expression Language (EL) für die Konfiguration.

Die finale Release 3.0 ist für die zweite Jahreshälfte 2009 geplant. Aktuell liegt Spring 3.0 als Milestone 2 (3.0.0.M2) vor. Auf die Frage, wie lange es noch Support für die Version 2.5 geben werde, wenn die Release 3.0 final sei, antwortete Wolff, dass es nach der Veröffentlichung von Spring 3.0 weiter Support für 2.5 gibt. Alle weiteren Änderungen am Sourcecode stehen nach wie vor zur Verfügung. Support-Kunden von SpringSource erhalten eine kompilierte Version. Aber es steht natürlich jedem frei, neue Versionen von Spring 2.5 selber zu kompilieren oder auf 3.0 aufzurüsten. Damit gibt es auch verlässliche Unterstützung für ältere Releases. Das Upgrade auf Spring 3.0 sollte kein großes Problem sein, da die APIs kompatibel bleiben sollen.

Spring 3.0 wurde komplett auf Basis von Java SE 5 (JDK 1.5) entwickelt. Somit ist die Mindestanforderung von Spring an die Ablaufumgebung eine"Java SE 5.0"-Plattform. Ältere Versionen des JDK finden keine Unterstützung mehr. Für das JDK 1.4.2 ist bekanntlich im Oktober 2008 das Ende des Lebenszyklus eingetreten. Es wird deswegen von Sun nicht mehr weiter gepflegt. Selbst die konservativsten Administratoren müssen jetzt langsam den Schritt nach Java 5 wagen.

In Folge der Aufräumarbeiten durch die Spring-Entwickler sind unter anderem die Apache Commons Attributes komplett verschwunden, die auf JUnit 3 aufsetzenden Klassen sind auf "deprecate" gesetzt. Das heißt, sie sind weiterhin vorhanden, werden aber in der Referenzdokumentation nicht mehr erläutert – und neue Projekte sollten sie nicht mehr nutzen. Die konsequente Verwendung von Annotationen für die Konfiguration erlaubt jetzt die Einbindung von Spring in JUnit 4 über die @RunWith-Annotation. Wolffs Empfehlung für das Testen von komplexen Anwendungen, die auf Datenbanken oder andere Systeme zugreifen, ist, für Unit-Tests Mock-Objekte zu verwenden. Für Integrationstests sollte weitgehend die Spring-Konfiguration für die Produktion genutzt und sie nur im Bereich der Infrastruktur an die Testumgebung angepasst werden.

Die @Autowired-Annotation erlaubt, sowohl Setter-Methoden als auch Methoden mit mehreren Parametern auszuzeichnen. Erwartet man mehrere Argumente für den Methodenaufruf, so verschaltet der Spring-Container nur Spring-Beans, die vom gleichen Typ sind wie der Parameter in der Methodendeklaration. Allerdings wird die @Autowired-Annotation durch die Spring IDE noch nicht aufgelöst, somit kann der Entwickler nicht auf Tool-Unterstützung bei der Pflege dieser Annotation zählen. Oft ist das aber auch nicht nötig, da es meistens nur einen Kandidaten für die Injizierung gibt. Aber wie oft hat man wirklich mehrere Implementierungen eines Interfaces?

Ein Teilnehmer erhoffte sich in Spring 3.0 eine Unterstützung für die Erstellung von Spring-Bean DSLs (Domain-Specific Languages). Das Feature ist mit dem Groovy Spring BeanBuilder realisiert und kann unter anderem mit Grails eingesetzt werden, sodass keine Notwendigkeit für eine Einbindung in das Spring Framework bestand, erklärte Wolff.

Ein häufig in Spring-Projekten auftretendes Problem beschrieb ein anderer Teilnehmer. Die Wahlfreiheit bei der Konfiguration hat seiner Meinung nach auch Nachteile. So favorisieren manchmal die Mitglieder eines Entwickler-Teams unterschiedliche Varianten der Dependency Injection und verwenden eine Mischung von Setter-, Constructor- und Field-Injection (Letztere nur mit Annotationen). Hier empfahl Wolff, dass der Architekt über Code-Konventionen die Vorgabe setzt, welche Art der Dependency Injection zu verwenden ist und das beim Review oder auch durch den Einsatz von Pointcut-Ausdrücken zur Compile-Zeit mit dem AspectJ-Compiler überprüft. Außerdem merkte der Referent an, dass die Flexibilität von Spring es ermöglicht, auf die spezifischen Anforderungen der einzelnen Projekte zu reagieren. Der Architekt muss dann die Alternative auswählen, die für das Projekt passt.