"Verstehen Sie mich nicht falsch, wir lieben Java" – Guillaume Laforge über Groovy 2.0

Java Magazin: Was bedeutet das für Groovy-2.0-Nutzer?

Guillaume Laforge: Die werden in der Lage sein, die neuen binären Literale zu verwenden, den Unterstrich in Nummernliteralen, den Diamond-Operator usw. Momentan das einzige nicht unterstützte Syntaxelement ist Try-with-Resource, da Groovy bereits viele Möglichkeiten bietet, Ressourcen innerhalb seines API zu verwalten, z. B. durch Streams, Dateien etc. Die Entscheidung, ob wir letztendlich auch Unterstützung für dieses Feature anbieten möchten, machen wir davon abhängig, ob es von Seiten unserer Userbasis nachgefragt wird.

Was auch interessant ist: Obwohl Aspekte von Project Coin erst in Java 7 und darüber hinaus verfügbar sind bzw. verfügbar sein werden, können Groovy-User von diesen Verbesserungen profitieren, wenn sie Groovy mit dem JDK 5 verwenden. Sie kommen also schon jetzt in den Genuss von Features, die ihnen eigentlich erst nach einem Upgrade auf das JDK 7 zur Verfügung stehen würden.

Java Magazin: Um genauer auf die wichtigsten neuen Aspekte der JDK-7-Unterstützung einzugehen: Warum haben Sie sich dafür entschieden, Unterstützung für Invoke Dynamic und statische Typprüfung hinzuzufügen? Gab es in der Groovy-Community die Forderung danach?

Guillaume Laforge: Wir fügen Invoke-Dynamic-Support hinzu, um von den Performanceverbesserungen für dynamische Sprachen zu profitieren, die das JDK 7 zur Verfügung stellt. Produktivität und eine straffe und effektive Syntax sind Dinge, die Groovy-Entwicklern grundsätzlich am Herzen liegen. Und die statische Typprüfung und Kompilierung wird vor allem Java-Entwicklern zusagen, die Vorbehalte gegenüber dynamischen Sprachen haben oder denen Typensicherheit und Geschwindigkeit à la Java wichtig ist. Das erhöht definitiv die Reichweite der Sprache, zieht neue Nutzer an und deckt mehr Anwendungsfälle ab.

Java Magazin: Welche Vorteile birgt die angestrebte Modularität und wie wird diese in Groovy verwirklicht?

Guillaume Laforge: Groovy wird in Form eines JAR geliefert, das man als Library im eigenen Projekt verwenden kann, und auch als Distribution mit Kommandozeilen- und UI-Tools und Third-Party-Libraries. Die Groovy-Bibliothek umfasst nicht nur die Sprache selbst (Parser, Compiler etc.), sondern auch viele zusätzliche Dinge wie Swing, JDK Collection Classes, Ant Scripting, JMX-Integration, Templating etc. Wie gesagt, nicht jeder braucht alles. Deshalb ist es wichtig, dass man nur die Dinge verwendet, die wirklich relevant sind, damit man weniger Abhängigkeiten im eigenen Projekt erzeugen muss.

Deshalb unterteilen wir die Groovy Sources und das JAR in kleinere Unterprojekte und Module, die am Ende eigene JARs mit speziellen Eigenschaften darstellen werden. Dann wird es möglich sein, bei Bedarf ein bestimmtes Modul ins eigene Projekt zu importieren. Dadurch können wir auch die Auswahl an APIs, die Groovy zur Verfügung stellt, erhöhen. In Anbetracht der Größe der Groovy-Runtime sind wir bislang nämlich etwas zögerlich, was neue API-Unterstützung angeht. Aber dank der Modularität wird es um einiges leichter sein, neue APIs hinzuzufügen.

Java Magazin: Nochmal zum Mitschreiben: Es wird trotzdem Unterstützung für den JDK 5 und 6 geben, oder?

Guillaume Laforge: Ja, der Plan ist, in Groovy 2.0 weiterhin das JDK ab Version 5 zu unterstützen. Wir haben immer noch Groovy-User, die noch immer auf dem JDK 5 sitzen. Auf die versuchen wir Rücksicht zu nehmen indem wir ihnen erlauben, Groovy weiterhin zu benutzen, bis sie die Gelegenheit haben, auf ein neueres JDK umzusteigen. Für spätere Groovy-Versionen werden wir sicher ein neueres JDK voraussetzen, vielleicht sogar JDK 7. Das steht noch zur Diskussion.

Java Magazin: Es gibt eine Reihe anderer, eigenständiger Projekte, die um Groovy herum entstehen, was sich als Zeichen der Anerkennung der Sprache werten lässt. Dazu gehören Gradle, Grails und GPars, das in Groovy 1.8 hinzukam. Haben diese Projekte auch etwas dazu beigetragen, dass eine so lebendige Community um die Sprache Groovy entstanden ist?

Guillaume Laforge: Groovy ist insgesamt sehr erfolgreich und wird von vielen Entwicklern weltweit für verschiedenste Projekte und Domains eingesetzt. Durch die vielfältigen Einsatzmöglichkeiten, die Ausdrucksstärke und andere Vorzüge lässt sich Groovy wunderbar in anderen Bibliotheken und Frameworks einsetzen. So ist ein großes Ökosystem um die Sprache herum entstanden, und dieses Ökosystem hat wiederum viele neue Nutzer angezogen: Grails ist ein sehr prominentes Beispiel, das viel Aufmerksamkeit auf Groovy gelenkt hat. Gradle ist ein Build-Automatisierungsprojekt, das Groovy verwendet und in vielen Enterprise- und Open-Source-Projekten wie Spring und Hibernate verwendet wird. Dieses Ökosystem ist ein wichtiger Erfolgsfaktor für die Sprache Groovy.

Java Magazin: Wie sieht die weitere Roadmap für Groovy aus?

Guillaume Laforge: Selbstverständlich gibt es schon Pläne für weitere Versionen. Im Einzelnen wollen wir den dynamischen Kern von Groovy (das Meta-Objekt-Protokoll) umarbeiten, um ihn homogener und leistungsstärker zu machen und feingranulare Kontrolle über dynamische Eigenschaften zu ermöglichen – und außerdem mehr Sicherheit, um die Reichweite von Änderungen in der Metaprogrammierung zu kontrollieren usw.

Zusätzlich werden wir unseren Parser neu schreiben. Eine neuere Version von Antlr soll verwendet werden, mit besserem IDE-Tooling, um die Grammatik von Groovy weiterzuentwickeln.

Auch die Bemühungen in Richtung Modularität werden fortgesetzt. Außerdem sind wir weiterhin ganz Ohr, was die Bedürfnisse unserer User betrifft, und werden ihren Wünschen nach Verbesserungen und neuen Features nachkommen.

Guillaume Laforge ist Project Lead von Groovy bei SpringSource. Mit Dierk König zusammen hat er den Bestseller „Groovy in Action“ verfasst. Er ist auf Konferenzen in aller Welt anzutreffen, wo er über Groovy, DSLs in Groovy, Grails und Gaelyk (ein leichtgewichtiges Toolkit für die Google App Engine) spricht.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.