Apache Groovy: Duck-Typing, statischer Typprüfer und der Gradle-Bootstrap mit gradle -p bootstrap

Groovy zwischen Duck-Typing und erweiterbarem statischen Typprüfer

Das README von apache/groovy bezeichnet Groovy als vielseitige Programmiersprache für die JVM-Plattform. Der Satz, der die Sprache am besten einordnet, betrifft das Spektrum der Programmierstile. Groovy erlaubt optionale Typisierung und Duck-Typing wie dynamische Sprachen, bietet zugleich aber statische Übersetzung und statische Typprüfung über einen erweiterbaren statischen Typprüfer. Für diesen Prüfer behauptet das README ein Niveau, das dem von Java entspricht oder darüber liegt.

In dieser Doppelheit liegt der Kern der Sprache. Wer ein kurzes Skript schreibt, lässt Typangaben weg. Wer dieselbe Logik in ein langlebiges System überführt, schaltet die statische Prüfung zu und erhält Fehler vor dem Start statt zur Laufzeit. Als Ziel nennt das README höhere Produktivität bei knapper, vertrauter und leicht erlernbarer Syntax.

An Fähigkeiten führt das README Skriptunterstützung auf, dazu das Verfassen domänenspezifischer Sprachen, Metaprogrammierung zur Laufzeit und zur Übersetzungszeit sowie funktionale Programmierung. Die Metadaten weisen Java als Sprache des Repositories aus, was bei einem Übersetzer in Java wenig überrascht. Zum Abrufzeitpunkt standen rund 5.500 Sterne und 1.913 Forks im Raum.

gitbox.apache.org, der schreibgeschützte Spiegel und gradle.properties

Zum Bezug der Quellen nennt das README zwei Wege. Der erste führt über das offizielle Git-Repository unter gitbox.apache.org/repos/asf/groovy.git. Der zweite geht über den Spiegel auf GitHub, der ausdrücklich als schreibgeschützt bezeichnet wird und der Bequemlichkeit sowie der Annahme von Beiträgen über Pull Requests dient.

Für reine Anwender ist diese Aufteilung ohne Belang, für Mitwirkende nicht: Wer ändern will, reicht beim Spiegel ein, während der maßgebliche Stand an anderer Stelle liegt. Das README sagt nicht, wie zügig Beiträge übertragen werden und ob beide Stände jederzeit übereinstimmen.

Der dritte Weg ist die Quellverteilung als Archiv. Wer sie nutzt und daraus bauen möchte, braucht einen zusätzlichen Schritt, weil das Archiv den Gradle-Wrapper nicht mitbringt. Jede Groovy-Version wird laut README mit einer bestimmten Gradle-Version gebaut und getestet, festgehalten in der Eigenschaft gradle_version in der Datei gradle.properties im Wurzelverzeichnis. Der Bootstrap erfolgt mit gradle -p bootstrap, danach wird ausschließlich gradlew verwendet.

gradlew clean dist mit JDK 17 und die Projektdateien für IDEA und Eclipse

Für den Bau gilt eine klare Vorgabe: JDK 17 oder neuer. Gebaut wird mit demjenigen JDK, das gradlew ausführt. Wer eine andere Bytecode-Stufe ansprechen oder Tests auf einem anderen JDK laufen lassen will, findet die Anleitung im Abschnitt Building and testing against a specific JDK in der Datei CONTRIBUTING.md.

Der zentrale Befehl lautet gradlew clean dist und erzeugt eine Distribution, die der Zip-Datei auf der Download-Seite entspricht. Für die Dokumentation steht gradlew asciidoc bereit. Eine Anmerkung des README verdient hier Beachtung: Die Codebeispiele der Dokumentation stammen aus tatsächlichen Testfällen. Beispiele sind damit gegen Änderungen an der Sprache abgesichert, statt unbemerkt zu veralten.

Für Entwicklungsumgebungen nennt das README zwei Befehle. gradlew jar idea erzeugt ein Projekt für IntelliJ, gradlew jar eclipse die Dateien für Eclipse. Zu Eclipse formuliert das README einen Vorbehalt, die Gradle-Struktur könne dort unter Umständen nicht vollständig abgebildet werden.

groovy, groovysh und groovyc aus installGroovy heraus

Wer die eigene Änderung als lauffähige Installation braucht, nutzt gradlew :groovy-binary:installGroovy. Das Ergebnis liegt unter subprojects/groovy-binary/build/install, und im zugehörigen bin-Verzeichnis finden sich die drei Startprogramme groovy, groovysh und groovyc.

Diese drei Namen beschreiben den Alltag mit der Sprache. groovy führt ein Skript aus, groovysh öffnet eine interaktive Konsole, groovyc übersetzt Quellen in Bytecode. Wer Groovy nur als Skriptsprache kennt, übersieht leicht, dass derselbe Werkzeugkasten auch die Übersetzung in Klassendateien beherrscht, die sich wie jede andere Java-Bibliothek verwenden lassen. Genau diese Doppelrolle macht die Sprache für Build-Logik attraktiv.

Für den Regelbetrieb ist dieser Weg nicht gedacht. Das README stellt ihn als Weg zu einer lokalen Installation mit den eigenen Änderungen dar. Veröffentlichte Pakete kommen dagegen von der Download-Seite unter groovy.apache.org/download.html, und Abhängigkeitserklärungen für Maven, Gradle und Ivy liegen als Ausschnitte auf den Seiten der einzelnen Module.

gradlew :test --tests groovy.GroovyMethodsTest gezielt einsetzen

Auch das Testen läuft über Gradle. Der vollständige Satz an Komponententests startet mit gradlew test. Soll nur ein einzelner Test laufen, lautet der Aufruf gradlew :test --tests <TestClassName>, wobei der Klassenname ohne Paketangabe erwartet wird. Das README nennt groovy.GroovyMethodsTest als Beispiel.

Für die Einarbeitung ist dieser Aufruf der schnellste Weg, eine einzelne Änderung abzusichern, ohne den gesamten Satz zu durchlaufen. Angaben zur Laufzeit der Testsuite fehlen im README, ebenso Zahlen zur erreichten Abdeckung; es verlinkt auf eine Abdeckungsauswertung, ohne Werte zu nennen.

Zur Infrastruktur gehört ein eigener Integrationsserver unter ci.groovy-lang.org, der laut README von JetBrains gesponsert wird, daneben ein Arbeitsablauf auf GitHub Actions. Für die Leistungsabstimmung nutzt das Kernteam nach README-Angaben einen Java-Profiler von YourKit, der ebenfalls gesponsert wird. Welchen Einfluss diese Sponsoringbeziehungen auf Ablauf und Reihenfolge der Veröffentlichungen haben, sagt das README nicht.

Groovy gegen Kotlin: Typdisziplin und die Frage nach den Releases

Eine Beobachtung betrifft die Veröffentlichung. Im Spiegel auf GitHub sind keine Releases hinterlegt, und die Metadaten nennen keine letzte Aktivität am Quellstand. Wer eine Version sucht, wird an die Download-Seite verwiesen. Für die Einschätzung heißt das: Veröffentlichungen finden außerhalb des Spiegels statt, und der Reifegrad lässt sich aus dem Repository allein nicht ablesen. Diese Lücke im Spiegel ist kein Hinweis auf Stillstand, verlangt aber einen Blick auf die offizielle Seite.

Als Alternative bietet sich Kotlin an, wenn die Sprache vor allem für Anwendungscode gedacht ist. Kotlin setzt auf durchgängige statische Typisierung und Nullsicherheit, während Groovy die Entscheidung zwischen dynamischer und statischer Prüfung offenlässt. Für Build-Skripte, domänenspezifische Sprachen und Skriptaufgaben, in denen Ausdruckskürze zählt, spielt Groovy seine Stärken aus. Bei umfangreichen Beständen mit wechselnden Mitwirkenden ist die strengere Prüfung häufig im Vorteil.

Die Apache-Lizenz 2.0 erlaubt den Einsatz in kommerziellen Produkten einschließlich angepasster Varianten, solange die Hinweispflichten beachtet werden; eine Gewährleistung ist ausgeschlossen. Ein Teil der Finanzierung läuft über eine Gemeinschaftsinitiative auf Open Collective, die das README ausdrücklich als Ergänzung zum Apache-Projekt darstellt.

Redaktionelles Fazit

Groovy eignet sich für Teams, die auf der JVM kurze Skripte, domänenspezifische Sprachen oder Build-Logik schreiben und die Entscheidung zwischen dynamischer und statischer Typprüfung offenhalten wollen. Wer Anwendungscode in großem Umfang baut, ist mit Kotlin und dessen durchgängiger Nullsicherheit oft besser beraten. Vor dem Einsatz sollte der Bau mit JDK 17 über gradlew clean dist durchlaufen und mit gradlew :test --tests groovy.GroovyMethodsTest geprüft werden, ob die eigene Umgebung den Testbetrieb trägt.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository