Die objektorientierte Script-Sprache Groovy liegt seit Anfang des Jahres in Version 1.0 vor. Die Sprache, welche auch unter dem JSR 241 spezifiziert wird, zeichnet sich durch ihren hohen Integrationsgrad mit Java aus. Groovy-Programme können vollständig auf einer Java Virtual Machine (JVM) ablaufen und haben damit auch vollen Zugriff auf Java-Objekte und so auf die Java-Klassenbibliotheken. Wir haben Groovy-Entwickler (Member) und Java Magazin-Autor Dierk König zum Status quo von Groovy befragt.

Dierk, stell dich doch bitte unseren Lesern kurz vor.
Dierk König: Ich arbeite für die Canoo Engineering AG in Basel als Softwareentwickler und Berater. Nach meinem Informatik-Studium in Karlsruhe bin ich in die Schweiz gegangen und habe für eine der großen Banken in einer Technologiegruppe gearbeitet, vornehmlich mit Java. Anfang 2000 haben wir Canoo gegründet, wo wir Softwareprodukte herstellen und für unsere Kunden Projekte durchführen.

Seit wann bist du in das Groovy-Projekt involviert und wie kam es dazu?
König: Mitte 2004 habe ich für unser Open-Source-Tool Canoo WebTest, das auf Ant aufbaut, eine Möglichkeit gesucht, mehr dynamisches Verhalten einbinden zu können. Als "alter" Perl- und Ruby-Hase habe ich mich nach Script-Sprachen umgesehen, die ähnlich mächtig sind, sich aber als zusätzliche Anforderung auch gut mit Java und Ant vertragen. Groovy hat bei meiner persönlichen Evaluierung mit Abstand am besten abgeschnitten und sich seitdem als hervorragende Wahl erwiesen. Aber es war noch viel an Groovy zu tun und ich habe ein paar Patches, Tests und Dokumentation beigesteuert, womit ich bald zum Committer wurde.

Worin grenzt sich Groovy von anderen Script-Sprachen ab? Es gab zum Beispiel Diskussionen dazu, ob Groovy nun eine "normale" Script-Sprache oder eine "dynamische Sprache" ist.
König:Die Hauptabgrenzung ist die Kombination aus Funktionsreichtum und Java-Freundlichkeit. Groovys Syntax ist für einen Java-Entwickler leicht eingängig. Groovy ist speziell für die JVM entworfen - unter voller Berücksichtigung der Java-Architekturen: des Objektmodells, des Laufzeitmodells, der Threading- und der Security-Architektur. Egal ob eine Klasse in Java oder Groovy geschrieben ist: Man kann sie gegeneinander austauschen. Dazu muss eine Script-Sprache statische Typen unterstützen und nach Bytecode kompilieren.

Groovy ist aber auch funktionsreich und dynamisch, was unter anderem für die elegante Bereitstellung von Closures bedingt, dass man dynamische Typisierung unterstützt. Diesen scheinbaren Widerspruch löst Groovy durch das Konzept der optionalen Typisierung auf: Wo statische Typen zum Beispiel für das Disambiguieren von überladenen Methoden gebraucht werden, kann man sie verwenden. Wo sie dem Programmierer im Weg sind, kann man sie weglassen. Groovy bietet das beste beider Welten.

Wer ist eher die Zielgruppe von Groovy? Die Java-Entwickler oder eher die Script-Sprachen-Entwickler, die die Mächtigkeit und Vielschichtigkeit der Java-Plattform kennen lernen wollen?
König: Als Hauptzielgruppe sehe ich die Java-Entwickler, die ihre Java-Projekte partiell um dynamische Eigenschaften erweitern wollen. Hier kann Groovy seine hervorragende Integation mit Java voll ausspielen. Alle anderen Anwender sind natürlich genauso willkommen und gerade im Umfeld von Grails gibt es auch vollständig in Groovy entwickelte Lösungen wie zum Beispiel www.aboutgroovy.com. In jedem Fall geht man ein niedriges Risiko ein und hat den vollen Investitionsschutz, weil man jederzeit zu Java zurückgehen kann - sogar sehr feingranular bis auf Klassenebene.

Groovy ist nun in Version 1.0 erschienen. Was sind hier für dich die wichtigsten Features?
König: Die Haupteigenschaft von Groovy 1.0 ist die verbindliche Baseline. Es ist die verlässliche Sammlung der Spracheigenschaften. Die Syntax hat sich über einen längeren Zeitraum stabilisiert und wurde im letzen Jahr nur an einer kleinen Stelle angepasst. Dieser Zustand ist nun in einen Release gegossen.

Was ist zukünftig geplant und wie lange wird man darauf warten müssen? Es hat ja eine Weile gedauert, bis die Version 1.0 fertig war.
König: Ende Januar trifft sich die Expertengruppe auf der GroovyDevCon in Paris und beschließt, welche Wünsche von der langen Liste in den Release 2.0 kommen. Meine Vermutung ist, dass dieser Release auch mindestens ein Jahr dauern wird, selbst mit Committern, die ihre volle Arbeitszeit in Groovy investieren können.

Worin siehst du den Vorteil, dass Script-Sprachen wie Groovy, Ruby etc. neuerdings massiven Einfluss auf Sprachen wie Java bekommen?
König: Einen massiven Einfluss auf die Syntax sehe ich nicht. In Java wird es zum Beispiel niemals Closures geben. Das muss auch nicht sein. Java ist sehr gut, so wie es ist. Es fokussiert sich darauf, "powerful" zu sein unter Einschränkung der Flexibilität, wie James Gosling zurecht sagt. Flexibilität kann man durch den Mix mit Groovy erreichen. Hier helfen die Bestrebungen der JSR 223 (Scripting for the Java Platform) und der JSR 292 (Supporting Dynamically Typed Languages on the Java Platform).

Domain-spezifische Sprachen, kurz DSLs, kommen in Mode. Was steckt dahinter und wie unterstützt Groovy DSLs?
König: DSLs sind Sprachmittel, um fachliches Wissen zu formulieren und direkt ausführbar zu machen. Sie erleichtern die Anforderungsanalyse, das Testen, die Zusammenarbeit mit dem Kunden und die Anpassung an neue Anforderungen, sprich die Wartung. Je nach Anwendungsdomäne können DSLs ganz unterschiedlich aussehen: als Schlüsselworte, Tabellen, XML, grafische Repräsentationen usw. Dynamische Sprachen wie Groovy eignen sich prinzipiell immer gut, um DSLs zu implementieren. Das originäre "Builder"-Konzept von Groovy tut ein Übriges.

Wie "Enterprise"-ig ist Groovy?
König: Für Unternehmen, die auf Java setzen, ist Groovy die natürliche Wahl bei allen Anforderungen, die dynamisches Verhalten bedingen. Das kann man mittlerweile in den Fortune-500-Unternehmen sehen. Hier ist vor allem der Investitionsschutz in die entwickelten Java-Komponenten, Frameworks und Plattformen vorrangig.

Welche Projekte, die auf Groovy basieren oder Groovy benutzen, sind besonders nennenswert?
König: Der Top-Kandidat ist ganz klar Grails. Das anzusehen ist ein Muss für jeden Java-/Enterprise-Entwickler. Mein persönlicher Kandidat ist Canoo WebTest, weil es die vielen verschiedenen Vorzüge der Integration von Groovy und Java zeigt. Dann darf man natürlich auf keinen Fall Spring vergessen. Darüber hinaus haben so gut wie alle Open-Source-Projekte, die per Scripting erweiterbar sind, eine Einbindungsmöglichkeit für Groovy.

Im Rahmen des JCP tut sich bei dem JSR 241, der Groovy spezifizieren soll, schon seit längerer Zeit nur wenig Sichtbares. Weißt du hierüber Näheres?
König: Der JSR muss eine Referenzimplementierung (RI) liefern, ein Test Compatibility Kit (TCK) und die Groovy Language Specification (GLS). Bisher lag der Fokus auf der RI, die mit Groovy 1.0 fertiggestellt ist. Das TCK ist noch sehr schwach bestückt. Man kann sie aber mit den Unit-Tests der RI auffüllen. Die GLS ist vollständig, was die Grammatik betrifft, die im Antlr-Format vorliegt. Der "Prosa"-Teil ist als Differenz zur Java Language Specification ausgelegt und bedarf noch einiger Arbeit.