Spring 3 steht vor der Tür - ein erster Ausblick
Seite 2: Aufräumarbeiten
Aufräumarbeiten
In einigen Bereichen findet man allerdings neue Ansätze, die alte ersetzen. So hatte Spring 2.5 im Web-Bereich bei Spring MVC Controller und Unterstützung für Tests eingeführt, die auf JUnit 4 und Annotationen aufsetzen. In diesen Bereichen sind die alten Ansätze wesentlich weniger elegant, sodass sie als "deprecated" abgelegt sind. Dazu zählen Teile der Web-Controller-Hierarchie (zum Beispiel SimpleFormController) aus Spring MVC und die JUnit-3-Klassen (AbstractDependencyInjectionSpringContextTests). Der Entwickler sollte in neuen Projekten auf diese nun außen vor gelassenen Klassen verzichten. Die Referenzdokumentation stellt sie erst gar nicht mehr vor, um neue Nutzer nicht auf den falschen Weg zu führen. Unberührt bleibt davon die Javadoc-Dokumentation.
Neben den als veraltet markierten Elementen haben die Spring-Entwickler einige Dinge sogar aus dem Framework entfernt. Dazu gehört die Unterstützung für Commons Attributes. Diese Technik konnte man nutzen, um mit JDK 1.4 ähnliche Optionen wie mit Java-5-Annotationen zu haben. Da Java 5 die neue Basis darstellt, ist das Feature überflüssig. Ebenfalls gestrichen ist die Unterstützung für die proprietäre TopLink-API – Oracle propagiert statt dieser mittlerweile die Java Persistence API (JPA). Die Unterstützung für Struts 1.x ist ebenfalls entfallen. Hier gibt es sicher noch viele Nutzer, doch mit SpringBeanAutowiringSupport steht eine neue Alternative zur Verfügung. – Die Struts-2-Entwicklungsschiene basiert übrigens selber auf Spring, sodass hierfür keine Integration von Spring angeboten werden muss.
Durch diese Aufräummaßnahmen möchten die Spring-Entwickler gewährleisten, dass das Framework auch in Zukunft dem Motto "Simple yet powerful" entspricht. Ohne solche Maßnahmen würde die Einarbeitung zunehmend schwerer sein, und zwar nur, weil es zahlreiche Features mitschleppt, die niemanden mehr interessieren. Ansonsten bleibt Spring dem Ziel der Rückwärtskompatibilität verpflichtet. 100 Prozent der APIs und 95 Prozent der Extension Points sollen der Version 2.5 entsprechen.
Eine andere Änderung betrifft das Projekt-Layout. Spring war schon immer stark modularisiert. Dennoch gab es das spring.jar mit allen Modulen in einer Datei und sogar eine Distribution mit allen abhängigen Libraries. Obwohl einige Nutzer das als Vorteil sehen, ging Spring damit in den Bereich des Abhängigkeitsmanagements, da es eine Umgebung aus unterschiedlichen Bibliotheksversionen definiert. Das sollte man besser anderen Techniken wie Maven, ivy oder OSGi überlassen.
Dementsprechend gibt es in Spring 3 nur noch einzelne Spring-Module, die man über OSGi oder Maven einbindet. Für die abhängigen Bibliotheken unterstützt das Framework auch diese beiden Techniken. Gleichzeitig stellt SpringSource mit dem Enterprise Repository (siehe Glossar) eine Sammlung von Bibliotheken zur Verfügung, die im OSGi-Kontext getestet sind. Auf dieser Basis kann man sein Projekt mit weiteren Bibliotheken versehen und auf OSGi, ivy oder Maven als etablierte Techniken für Abhängigkeitsmanagement zurückgreifen.
