Einsatz und Grenzen von Spring Roo

Werkzeuge  –  0 Kommentare

100 Prozent Java, gleichzeitig schnell und mit nur wenig Aufwand verbunden – Spring Roo verspricht viel, wenn es um die Entwicklung von Anwendungen für die Java-Plattform geht. Doch bevor das Känguru (der Namensgeber des Projektes) durchs Dorf getrieben wird, gilt es abzuwägen: Wann ergeben die Konzepte wirklich Sinn und für wen kommt Spring Roo in Frage?

Anwendungen werden immer größer, komplexe Schnittstellen immer zahlreicher, und auch der Umfang an Quellcode steigt unerbittlich. Die Folge sind ein höherer Aufwand und zunehmende Kosten für die Entwicklung und Wartung von Anwendungen. Das Open-Source-Projekt Spring Roo wirbt mit "Rapid Application Development" und verspricht eine Lösung für genau diese Probleme: Dem Entwickler soll viel Arbeit abgenommen und dadurch schneller Ergebnisse erzielt werden können. Doch was genau verbirgt sich hinter Spring Roo? Und viel wichtiger: Was kann Spring Roo leisten, und was können Entwickler damit anfangen?

Zu Spring Roo existieren bereits viele Einführungsartikel und Tutorials, etwa auf springsource.org. Soviel vorweg: Dieser Artikel soll kein weiteres Tutorial für die Entwicklung mit Spring Roo sein, sondern einen Überblick zu den eingesetzten Konzepten geben und das Potenzial des Projekts aufzeigen. Denn um die Vorteile des versprochenen "Rapid Application Development" tatsächlich nutzen zu können, sollte der Entwickler wissen, für welche Projekte Spring Roo sinnvoll ist, aber auch wann keine Vorteile entstehen.

Spring Roo ist ein Werkzeug, mit dem sich Java-Anwendungen einfach und effizient realisieren lassen, und zwar ausschließlich mit bekannten und verbreiteten Java-Techniken wie Spring, dem Java Persistence API (JPA), JUnit oder Googles Web Toolkit (GWT). JVM-Programmiersprachen wie Groovy oder Scala kommen nicht zum Einsatz. Ein Vorteil: Der Entwickler muss relativ wenig Quellcode schreiben, obwohl "nur" Java zum Einsatz kommt. Den zusätzlich benötigten "Boilerplate-Code" generiert Spring Roo. Auch beim Refactoring oder bei Upgrades auf neue Versionen der eingesetzten Frameworks (inklusive Spring Roo selbst) übernimmt die Software diese Aufgaben.

Entwickler müssen neben dem eigentlichen Schreiben von Quellcode noch viele weitere Aspekte wie Build-Skripte, das Management von abhängigen Bibliotheken, Architekturmuster, die Framework-Auswahl oder Persistenzstrategien bedenken. Java-Enterprise-Anwendungen zu entwickeln ist daher ein aufwendiger Prozess. Spring Roo übernimmt hierbei die "schmutzige Arbeit" und kümmert sich um viele dieser Aufgaben automatisch im Hintergrund, indem es einen Großteil der Konfiguration generiert und benötigte Bibliotheken einbindet.

Spring Roo besteht aus einer Sammlung von Tools, APIs und Frameworks. Erst das gute Zusammenspiel dieser Teile ermöglicht es dem Entwickler, Anwendungen effizient zu entwickeln.

Die Roo-Shell ist hier der zentrale Koordinator. Sie lässt sich über die Kommandozeile oder innerhalb der Entwicklungsumgebung (IDE) starten. Die Interaktion läuft über spezifische Befehle, auf die die Roo-Shell reagiert, indem sie Java-Klassen und andere Ressourcen generiert, beziehungsweise bei Änderungen aktualisiert. Als Build-System kommt Maven zum Einsatz. Alle benötigten Bibliotheken werden so automatisch in der Konfigurationsdatei pom.xml verwaltet und aus dem Repository heruntergeladen.

Entwickler können über die Roo-Shell mit wenigen einfachen Kommandos beispielsweise Entitäten generieren, inklusive deren Beziehungen sowie zugehöriger CRUD-Weboberfläche (Create, Read, Update, Delete) zur Verwaltung der Daten. Dabei wird das Konzept "Convention over Configuration" verfolgt, nach dem der Entwickler nur das konfigurieren muss, wofür die Standardeinstellung nicht ausreicht.

Zudem fügt die Shell den Java-Klassen Annotationen hinzu. Alternativ können Roo-Annotationen auch per Hand in den Java-Klassen ergänzt werden, die Roo-Shell generiert in dem Fall automatisch die zugehörigen Funktionen. So fügt beispielsweise die Annotation @RooJavaBean zu einem Attribut die Getter- und Setter-Methoden hinzu. Allerdings ist Spring Roo kein Runtime-Framework. Die Annotationen sind nur während der Kompilierung sichtbar und werden dann entfernt.

Ein weiteres wichtiges Konzept von Spring Roo ist die aspektorientierte Programmierung (AOP). Diese ist mit AspectJ umgesetzt. Mithilfe der Bibliothek lässt Java-Quellcode sich in Aspekte (.aj-Dateien) auslagern. Das Mapping zwischen der eigentlichen Java-Klasse und den Aspekten entsteht durch die Roo-Annotationen und den AspectJ-Compiler. Während der Kompilierung werden die Aspekte schließlich in den Java-Bytecode integriert.

Im Fall von Spring Roo lagert AspectJ Quellcode, der immer wieder gleich umzusetzen ist (beispielsweise Getter-/Setter- oder eine toString-Methode), in eigene Aspekte aus. Der Entwickler muss die so generierten Dateien nicht bearbeiten, stattdessen aktualisiert Spring Roo sie automatisch. Das ist auch der Grund dafür, dass Aspekte in der Entwicklungsumgebung standardmäßig gar nicht sichtbar sind. Sofern der Code eigene Anpassungen erfordert, zum Beispiel um einer Setter-Methode zusätzliche Logik hinzuzufügen, lassen sich durch "Push-in"-Refactoring einzelne Teile der Aspekte in die Java-Klasse verschieben.

Spring Roo simuliert mit dem Einsatz von AOP und Code-Generierung die Vorteile dynamischer Programmiersprachen und schafft so ein ähnlich "dynamisches Feeling". Da ist es kein Zufall, wenn Entwickler sich beim Einsatz von Spring Roo an das Web-Framework Grails – das übrigens auch von Springsource entwickelt wird – erinnert fühlen. Nur läuft die Entwicklung eben mit der statischen Programmiersprache Java statt mit dem dynamischen Groovy.

Ein weiteres wichtiges Konzept von Spring Roo ist die Erweiterbarkeit. An sogenannten Extension Points lassen sich eigens entwickelte Add-ons anbinden. Mittlerweile sind diverse solcher Add-ons von Drittanbietern verfügbar oder gerade in Arbeit. Viele Anbieter von Web-Frameworks machen davon Gebrauch, um ihr eigenes Framework, genau wie die implizit unterstützten Spring MVC und GWT, einzubinden. Aber auch eigene, unternehmensinterne Add-ons können relativ einfach erstellt werden.