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

Java Magazin: Groovy wird als sehr mächtige Sprache beschrieben, die Konzepte von Java und anderen Sprachen in sich vereint. Worin unterscheidet sich Groovy von anderen JVM-Sprachen und Domain-Specific Languages (DSLs)?

Guillaume Laforge: Sie haben gerade schon zwei Sweetspots von Groovy genannt. Ich würde noch einen dritten hinzufügen, nämlich die Skriptfähigkeit und Einbettbarkeit. DSLs sind in Groovy einfach zu schreiben, dank des konzisen und flexiblen Charakters der Sprache und ihrer Metaprogrammierfähigkeiten. Man kann z. B. Nummern zu Properties hinzufügen, fast schon normale englische Sätze schreiben, bestimmte Operatoren überladen etc. Durch all diese Techniken wird die Businesslogik noch lesbarer und einfacher zu verstehen und in Stand zu halten als wenn man lediglich ein Java-API verwenden würde. Deshalb wird Groovy häufig als Business-Sprache in vertikalen Applikationen genutzt – im Finanz- und Gesundheitssektor etc.

Das alles ermöglicht auch der dritte Punkt, den ich erwähnt habe: dass man Groovy leicht in eine Java-Anwendung einbetten kann (Spring, Java EE, jedes Framework). Auf diese Weise kann Groovy den Aspekt der Businesslogik abdecken, während der Infrastrukturcode schlicht Java ist.

Java Magazin: Und worin unterscheidet sich Groovy von Abstract Syntax Tree (AST) Transforms?

Guillaume Laforge: AST Transforms sind eigentlich im DSL-Aspekt inbegriffen, da es sich hier um eine Technik handelt, mit der man die Groovy-Sprache manipulieren kann, um sie auf einen bestimmten Bedarf im Geschäftsumfeld zuzuschneiden. Man kann die Syntax der Sprache aufbrechen, sie zurechtbiegen oder dem eigenen Gebrauch gemäß einschränken, um die Konzepte der Domain, an der man arbeitet, besser darin abzubilden.

Java Magazin: Welche Ziele werden mit Groovy 2.0 in puncto Features verfolgt?

Guillaume Laforge: Bei einer halben Million Groovy-Usern ist es klar, dass die Sprache völlig unterschiedlich eingesetzt wird und nicht jeder dieselben Dinge braucht. Einige Groovy-Nutzer schreiben komplette Applikationen in Groovy, während andere nur Groovy-Businessregeln in ihre Java-Applikationen einbetten. Einige benutzen Groovy als eine Art flexibleres Java. Wieder andere machen sich die Performance für anspruchsvolle Berechnungen zunutze. Schließlich gibt es User, die die Templating-Fähigkeiten interessieren, aber nicht die Swing-UI-Möglichkeiten. Oder umgekehrt. Deswegen lag in diesem Release unser Augenmerk auf Sicherheit, Performance und Modularität.

Java Magazin: Können Sie diese drei Aspekte näher erläutern?

Guillaume Laforge: Stichwort Sicherheit: Java-Entwickler, die Groovy als ein flexibles Java verwenden, tendieren dazu, Groovy genauso zu nutzen wie Java. Sie nehmen also nicht die dynamischen Aspekte von Groovy in Anspruch. Für einfache Fehler wie Tippfehler in Methoden- oder Variablennamen oder fehlerhafte Typen bei deren Zuweisungen etc. würden sie Compilezeitfehler bekommen. Deswegen stellt Groovy eine neue AST-Transformation vor, die Typprüfung zur Compilezeit umfasst. Dadurch „nörgelt“ der Compiler häufiger, d. h. er beschwert sich auch über gewöhnliche Fehler.

Stichwort Performance: Wenn man die dynamischen Fähigkeiten nicht braucht, kann man den Code genauso gut auf den gleichen Bytecode kompilieren, den Java-Code generiert, in derselben Geschwindigkeit wie Java! Das ist ein ziemlich überzeugendes Argument für alle, die bevorzugt an Real-Time-Systemen usw. arbeiten. Aber auch der, der auf die dynamischen Fähigkeiten von Groovy setzt, hat gute Karten, denn der Invoke-Dynamic-Support im JDK 7 wird einige schöne Performanceverbesserungen mit sich bringen, auch für die dynamischen Teile der Anwendungslogik.

Was den Aspekt „nicht jeder braucht alles“ betrifft: Wir konzentrieren uns auf Modularität, splitten also die Groovy-Bibliothek in kleinere Module auf. So können User nur die Module aufgreifen, die sie interessieren, z. B. wenn ich Ant-Skriptfähigkeit möchte, aber keinen Swing-Support; oder Templating-Fähigkeiten, aber keinen JMX-Support usw. Dadurch können wir unsere APIs einfacher weiterentwickeln, damit wir irgendwann mit neueren und besseren APIs als den jetzigen aufwarten können.

Kommentare

Schreibe einen Kommentar

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