© Razym/Shutterstock.com
Groovy: lange Tradition, breite Benutzerbasis

Java-Tanz


Groovy kann in vielerlei Hinsicht als Urvater des Gedankens angesehen werden, eine überall verfügbare Runtime wie die JVM als Ausführungsumgebung für eine beliebige andere Programmiersprache zu verwenden. Schon aus diesem Grund wollen wir hier einen kurzen Blick darauf werfen, was Groovy auszeichnet und wie man es schnell in Betrieb nimmt.

Das von der Apache Foundation vorangetriebene Groovy-Projekt ist im Vergleich zu Projekten wie TypeScript oder CoffeeScript geradezu methusalemisch – der Release 1.0 der Sprache erfolgte schon im Jahr 2007. Seither erfreut sich der Java-Ableger konstanter Beliebtheit.

Vom Konzept bzw. Problem

Die Einführung einer neuen Programmiersprache – sei es ein Web-Plug-in oder etwas anderes – scheitert im Allgemeinen am Henne-Ei-Problem. Hat das Plug-in noch nicht genug Verbreitung auf dem Markt, so wollen Entwickler es nicht einsetzen, weil die von ihnen erzeugten Kompilate keine Kunden erreichen. Ohne Produkte kann das Plug-in allerdings auch keine Kunden erreichen.

Der Gedanke von Systemen wie Groovy besteht darin, eine schon vorhandene Ausführungsumgebung – hier beispielsweise die JVM – zu kapern. Der eigentliche Lebenszyklus einer Groovy-Applikation beginnt auf der Workstation des Entwicklers, wo der Compiler den Groovy-Quellcode in eine reine Java-Anwendung umwandelt. Im Zusammenspiel mit einer .jar-Datei, die die sonstigen Groovy-Elemente bzw. Funktionen zur Verfügung stellt, entsteht dann ein normales Java-Programm.

Beachten Sie, dass diese Transpilation normalerweise auf der Entwickler-Workstation erfolgt. Zur Laufzeit haben wir es mit einem gewöhnlichen Programm zu tun, das in Form von JVM-Bytecode vorliegt.

Einrichtung der Arbeitsumgebung

Wie die meisten anderen Sprachcompiler ist auch Groovy – in der Theorie – auf der Kommandozeile problemlos lebensfähig. Bequemer ist es allerdings, wenn man Compiler und sonstige Toolchains in eine IDE einbindet.

Freunde der Java-Entwicklung denken hier nur allzu häufig an Eclipse. Erfreulicherweise steht ein Plug-in zur Verfügung, das vorhandene Eclipse-Installationen aufrüstet. In der Praxis ist es bequemer, eine weitere Stand-alone-Version der Entwicklungsumgebung in Betrieb zu nehmen. VMware nutzt sie intensiv als Teil seiner Spring-Arbeitsumgebung, weshalb unter [1] ein vorgefertigtes Eclipse-Paket für Windows, macOS und Linux gleichermaßen zur Verfügung steht.

Wer wie der Autor in den folgenden Schritten mit Ubuntu Linux 20.04 arbeiten möchte, klickt im ersten Schritt auf den Knopf 4.10.0 – LINUX 64-BIT. Die Webseite reagiert darauf mit der Bereitstellung der etwa 500 MB großen Datei spring-tool-suite-4-4.10.0.RELEASE-e4.19.0-linux.gtk.x86_64.tar.gz, die Sie in einem mehr oder weniger beliebigen Verzeichnis entpacken. Danach erfolgt der Start der integrierten Entwicklungsumgebung nach dem folgenden Schema:

tamhan@TAMHAN18:/media/tamhan/f4f8afc0-a87e-4cff-8591-6dc4a047a1e6/sts-4.10.0.RELEASE$ ./SpringToolSuite4 org.eclipse.m2e.logback.configuration:

Interessant ist in diesem Zusammenhang vor allem, dass VMware der hauseigenen Eclipse-Variante die Verwendung eines eigenen Workspace zuweist, der von anderen Eclipse-Versionen normalerweise nicht verwendet wird. Lohn dieser Anpassung ist, dass Sie Ihre vorhandene Eclipse-Version problemlos weiterverwenden können.

Interessanterweise führt das soeben durchgeführte Herunterladen nicht dazu, dass wir eine für die Stand-alone-Entwicklung geeignete Arbeitsumgebung erhalten. Zur Lösung dieses Problems besuchen wir im ersten Schritt die GitHub-Seite unter [2], wo wir das in Abbildung 1 gezeigte Symbol sehen. Es lässt sich per Drag and Drop – ganz analog zu einer Quellcodedatei – in die laufende VMware-Eclipse-Instanz werfen, die daraufhin mit der Einblendung eines Dialogs zum Herunterladen von Software reagiert.

hanna_groovy_1.tif_fmt1.jpgAbb. 1: Dieses Symbol hat magische Fähigkeiten

Zum Zeitpunkt der Drucklegung wird Ihnen die IDE neben einer stabilen Version des Groovy-Compilers 3.0 auch eine Access-Variante 4.0 anbieten – der Autor wird in den folgenden Schritten beide gleichermaßen installieren. Im nächsten Schritt müssen Sie noch eine Gruppe von Lizenzbedingungen abnicken, danach beginnt auch schon das Deployment.

Hello World mit Groovy

Über die Frage, wie man eine Programmiersprache am besten vermittelt, lässt sich hervorragend streiten. Wir wollen in den folgenden Schritten am lebenden Objekt lernen, weshalb wir nach dem obligaten Neustart auf die Option File | New | Other klicken. Eclipse bietet daraufhin den bekannten Projektgeneratordialog an, in dem wir uns für die Option Groovy | Groovy Project entscheiden. Im Bereich der Namensvergabe haben Sie im Allgemeinen freie Hand – der Autor verwendet in den folgenden Schritten den String SUSGroovy1.

Die restlichen Einstellungen des Assistenten können wir im Allgemeinen unberührt lassen – nach dem Anklicken von Finish erhalten wir ein neues Projekt, das allerdings noch keine Quellcodedatei aufweist.

Im Interesse der Lustigkeit erzeugen wir im nächsten Schritt ein neues Paket; der Autor wird es in den folgenden Schritten suspacket nennen. Im nächsten Schritt klicken wir das neu erzeugte Paket an und entscheiden uns für die Option File | New | Other.

Das Erzeugen einer neuen Groovy-Datei erfolgt unter Nutzung des Vorbilds aus der Vorlage Groovy | Groovy Type (Abb. 2) – das Entwicklerteam hinter dem Eclipse-Plug-in hat diese Vorlage vor einiger Zeit umbenannt, weshalb Sie in älterer Dokumentation statt dem hier verwendeten String noch die ältere Variante Groovy | Groovy Class finden können.

hanna_groovy_2.tif_fmt1.jpgAbb. 2: Die Option Groovy Type erzeugt neue Groovy-Dateien

Im nächsten Schritt fragt das Werkzeug, wie in Abbildung 3 gezeigt, nach der Art der zu erzeugenden Ressource und nach ihrem Namen. Wir wollen hier als Name susstarter.groovy vergeben und entscheiden uns für eine Klasse.

hanna_groovy_3.tif_fmt1.jpgAbb. 3: Der Grund der Umbenennung ist dieser Assistent

Im nächsten Schritt adaptieren wir den schon in der Datei befindlichen Inhalt nach folgendem Schema:

package suspackage class susstarter { static void main(String... args) { println 'Groovy world!' } }

Im Prinzip finden Java-Programmierer hier Gewohntes: Die vom klassischen Java bekannte Einsprungpunktmethode main ist auch hier mit von der Partie. Interessant sind allerdings einige Änderungen – erstens muss man Statements nicht mehr mit einem Semikolon abschließen. Andererseits ist die Verwendung eines Semikolons nach wie vor erlaubt, was dienstalte Knochen beruhigt.

Zweitens fällt auf, dass das in Java sonst notwendige umfangreiche Importieren von Paketen hier nicht wirklich notwendig ist. println ist dabei ein direktes Kommando – jede .groovy-Datei bekommt vom Compiler allerdings automatisch auch die folgende Gruppe von häufig verwendeten Importen eingeschrieben:

  • java.io.*

  • java.lang.*

  • java.math.BigDecimal

  • java.math.BigInteger

  • java.net.*

  • java.util.*

  • groovy.lang.*

  • groovy.util.*

Sonst können wir unser Programm hier auch schon zur Ausführung freigeben. Klicken Sie auf das Run-Symbol in der Toolbar und entscheiden Sie sich im daraufhin erscheinenden Auswahldialog für die Zieloption Groovy Console.

Lohn der Mühen ist eine nach dem Schema „java.lang.ClassNotFoundException: groovy.ui.Console“ aufgebaute Fehlermeldung. Zur Behebung legen wir eine weitere Run-Konfiguration an, entscheiden uns nun aber für die Vorlage Java Application. Nun sehen wir die erwartete Ausgabe der Begrüßungsmeldung in der Konsole.

Pakete sind ärgerlich

Mit C autodidaktisch ausgebildete Entwickler, die beispielsweise an einer Fachhochschule erstmals Kontakt mit Java bekommen, ärgern sich normalerweise über die Deklaration von Packages. Ein kleines Kommandozeilen- oder MSR-Programm bekommt man in den anderen Sprachen ja auch ohne den Tanz mit Paketen und sonstigen Strukturierungshilfsmitteln hin.

Das Groovy-Entwicklerteam begegnet dem Problem der „kurzlebigen Programmieraufgabe“ durch das Konzept des Skripts. An dieser Stelle wollen wir in die Datei susstarter.groovy zurückkehren und den in ihr enthaltenen Code nach folgendem Schema vereinfachen:

package suspackage println 'Groovy world!'

Für die Ausführung entscheiden wir uns dann für die Vorlage Run As | Groovy Script, im Konsolenfenster sehen wir abermals die Ausgabe der freundlichen Begrüßung. Ursache für dieses Verhalten ist, dass die Groovy Runtime ein ohne Package-Deklarationen angeliefertes Programm automatisch als Skript ansieht und es in einen Runner verpackt. Laut [3] gibt es dafür sogar eine dedizierte Basisklasse, deren im folgenden Schritt gezeigte Struktur grob an das bei Arduino implementierte Set-up-Run-Pattern erinnert (Listing 1).

Listing 1

import org.codehaus.groovy.runtime.InvokerHelper class Main extends Script { def run() { println 'Groovy world!' } static void main(String[] args) { InvokerHelper.runScript(Main, args) } }

Interessant ist in diesem Zusammenhang noch, dass Groovy bei derartigen Skripten unterschiedliche Variablensichtbarkeiten erlaubt. Deklariert man eine Variable mit einem Typ, so wird sie in der Run-Methode der zuvor abgedruckten Ausführungsklasse als lokale Variable angelegt. Nebeneffekt davon ist, dass sie von außen nicht sichtbar ist.

Deklariert man die Variable stattdessen ohne Datentyp...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang