Wie zuletzt angekündigt, widmen wir unsere Aufmerksamkeit den Closures widmen. Jedoch klären wir zuerst, was denn diese Closures sind? Der Begriff ist, wie 99% anderer auch, aus dem Englischen und hat im einfachsten Sinne etwas mit dem “Abschließen” von Code zu tun. Im Deutschen werden diese als Funktionsabschlüsse bezeichnet. Closures sind aber weder irgendein neuer Hype-Begriff, noch handelt es sich um eine komplexe Struktur. Per Definition handelt es sich bei Closures um Gebilde, die ihren Definitionskontext reproduzieren können, selbst wenn dieser von außen nicht mehr sichtbar, d.h. nicht existent ist. Praktisch orientierten Leuten kann man sicherlich einfacher damit helfen, indem man den Begriff der Anonymen Methoden und/oder der inneren Klassen in den Raum wirft. Genauso wie eine Anonyme Methode von außen nicht direkt ansprechbar ist (da ihr “Definitionskontext” unsichtbar ist, d.h. diese nicht über einen typischen Funktionskopf verfügen), so kann auch eine Closure in Groovy ohne einen Direktaufruf angewandt werden. Und nicht nur in Groovy, denn Closures sind schon seit der Programmiersprache LISP im Einsatz. Aber, schauen wir uns einfach ein Beispiel an, welches mit dem Auslesen von Dateien zu tun hat.

CLOSURES

Eine Klasse FileReader sorgt in ihrer statischen Main-Methode dafür, dass eine vorgegebene Datei mittels einer Closure ausgelesen wird. Die ganze Arbeit wird in diesem Abschnitt erledigt:

Das Objekt file ermöglicht mittels der Methode eachLine das zeilenweise Auslesen der Datei. Um sich den typischen Boilerplate-Code zu sparen, werden keine typischen “ist-die-Datei-zu-Ende”-while-Schleifen implementiert. Stattdessen wird eachLine syntaktisch so behandelt, als ob man genau an dieser Stelle eine neue Methode definiert. Man beachte die {}-Klammern, die bei Methodenaufrufen eigentlich nichts zu suchen haben. Eine Closure wird in diesem Beispiel als eine Referenz übergeben, was wiederum bedeutet, dass Closures Objekte sind.

Zugegeben, all das klingt recht unsinnig und man braucht schon seine Zeit, um sich damit anzufreunden, aber eigentlich ist eine Closure bloß eine Ansammlung von Code, welche sich eben wie ein Objekt verhält und dementsprechend übergeben werden kann. Zugleich aber kann sie wie eine Methode agieren, Parameter entgegennehmen und Werte zurückgeben. Mehr ist nicht drin. Wohl zum Glück

Im Falle der Anwendung von nur einem Parameter, bietet sich an, die interne Groovy-Variable it anzuwenden:

Jedoch bleibt die Frage im Raum, wo der eigentliche Nutzen von Closures zu finden ist? Ruft man sich in Erinnerung den zahlreichen Code, den man “drumherum” schreiben muss, nur um eine Collection zu durchwandern, oder aber eine Datei zu bearbeiten, so ist der Vorteil von Closures auf der Hand. Aber nicht nur die schnellere Erledigung von wiederkehrenden und somit auch langweiligen Aufgaben kann elegant mit Closures erledigt werden. Etwas Anderes, das nicht sofort ins Auge springt, lässt sich sehr einfach mit Closures erledigen. Und das ist die Trennung der Steuerungslogik vom aktuell zu bearbeitenden Code. Gesetzt den Fall, dass die obige Klasse nicht einfach die Datei auslesen muss, sondern auch jedes Zeichen in jeder gefundenen Zeile einzeln ausgeben soll, was müsste im Code getan werden?

Genau, nur der Code innerhalb der geschweiften Klammern muss geändert werden und die Steuerung selbst kann erhalten bleiben. Da bei jedem eachLine-Aufruf die Closure auf’s Neue aufgerufen wird, ist es klar, dass dieser Code nichts mit dem übrigen zu tun hat und problemlos ausgetauscht werden kann.

Hier lernen wir auch zugleich die Verarbeitung von Collections kennen. Und somit auch eine weitere Besonderheit von Groovy: alles kann zu einer Collection werden, denn alles ist ein Objekt und alle Objekte sind Collections von Daten und Methoden.

Warum ist das aber so?

Nun, es hat damit zu tun, dass in Groovy alle Objekte als Iterable gelten können und somit durchsuchbar sind. Da Groovy die Basisklasse Object von Java nicht nur übernommen, sondern diese auch um eine ganze Reihe von nützlichen Methoden erweitert hat, haben alle Subklassen von Groovy die Möglichkeit, unter anderem, auch spezielle Iteratoren zu implementieren, ohne auf die strukturierte Programmierung wie z.B. for-Schleifen zurückgreifen zu müssen. Stattdessen kann jedes denkbare Objekt “seine” Closures anwenden und innerhalb dieser Iteratoren laufen lassen.

Z.B. ist es bei Java ein Unding, wenn man sog. Closures entwickeln möchte. Da hat man früher oder später mit inneren Klassen zu tun und allerlei Problemen in Sachen Zugriffsrechte auf Klassenmember.

Auch ist Java keine dynamische Sprache, da deren Compiler im Voraus wissen muss, welchen Datentypen man benutzen wird, um eine bestimmte Variable zu initialisieren. Bei Groovy hingegen ist es ein Leichtes, eine Variable anzulegen und ihren Inhalt dann später, also per late-binding festzulegen.

Bei Java gibt es die Operatorüberladung nicht, weil man diese von C++ her bekannte Eigenschaft nicht weiter verwenden wollte. Nun, bei Groovy hat man diese Möglichkeit wieder.

Mit Groovy lassen sich sowohl reine Java-Applikationen entwicklen, als auch simple Skripte. Das Beste daran ist es, dass man als Programmierer/User gar nicht merkt, wie die ganzen Vorgänge im Hintergrund erledigt werden, denn ein Groovy-Programm wird auf die gleiche Art und Weise behandelt wie ein Skript oder gar ein Webservice. Auch ist es möglich mit Groovy COM-Komponenten zu steuern, Windows-Servies zu schreiben, Servlets usw. usf.

Da ich aber der Meinung bin, dass man alle Vorzüge (und auch Nachteile) der Sprachen erst durch deren Benutzung erkennen kann, zeige ich anhand einiger Beispiele in diesem und den nächsten Tutorials, was Groovy ist, was es kann und wozu es, meiner Meinung nach, gut ist.

INSTALLATION

Zuerst installieren wir aber den ganzen Batzen:

a) Um Groovy zu benutzen, muss man natürlich das jeweilige Package herunterladen.

b) Unter Windows entpackt man das Paket oder aber lädt den Installer herunter. Damit Groovy laufen kann, benötigt es natürlich eine zuvor installierte Java-Umgebung. Am besten ist die neue 1.6-er Version, auch wenn 1.5-er ihren Dienst tun würde. Jedoch schlägt die Benutzung von GraphicsPad unter Java 1.5 fehl, sodass ich doch die 1.6-er empfehle.

c) Vor der Installation sollte man sich auch vergewissern, dass JAVA_HOME unter den Umgebungsvariablen eingerichtet ist. Im PATH-Eintrag unter den Systemvariablen ist ebenfalls ein Eintrag %JAVA_HOME%\bin zu setzen, damit Groovy und seine Tools die Java-Komponenten finden können. Genauso muss auch GROOVY_HOME gesetzt werden. Und auch hier soll ein Eintrag %GROOVY_HOME%\bin im PATH stehen. Damit kann man wichtige Konsolentools von Groovy in der Kommandozeile anwenden.

d) Während der Installation wird man unter Windows eine Empfehlung erhalten, dass man doch ein paar zusätzliche Komponenten installieren sollte. Dieser Empfehlung sollte man nachgehen, da diese Komponenten viele nützliche Libs mit sich bringen, die man vielleicht später nützen wird.

e) Nachdem das Ganze installiert worden ist, wählt man im Menü Programme/Groovy den Eintrag “Starte GroovyConsole” aus. Auf den ersten Blick ist das neue Fenster recht “langweilig” anzusehen und man kann sich fragen, “wozu das Ganze”. Nun, jetzt beginnt der eigentliche Spaß, denn Groovy ist minimalistisch in Sachen Code-Vorarbeit und megalomanisch in Sachen Codier-Möglichkeiten. Denn Groovy ist aus zwei Gründen entstanden: einerseits ist Java als Sprache recht klein, jedoch sind die verschiedenen Libs derart mannigfaltig und aufgebläht, dass man sich nicht mehr fragen muss, ob in Java “etwas realisierbar ist”, sondern nur “womit ist dieses etwas zu realisieren”? Zweitens ist Java als Sprache in heutiger Zeit eher in eine solche Position geraten, neue Features einzufügen, wenn die Konkurrenz welche auf den Markt bringt. Das beste Beispiel ist C#3.0. Diese Version hat einige Elemente aus der funktionalen Programmierung übernommen, darunter auch die zuvor angesprochenen Closures, also wird sofort ein entsprechender Java-Standard gebastelt. C#3.0 implementiert LINQ (Language Integrated Queries) für eine vereinfachte DB-Verwaltung, also macht es Java nach. Usw. usf. Java ist eindeutig in einer defensiven Position, was eigentlich kein Grund zur Trauer wäre, denn nur so können Programmiersprachen (und andere IT-Komponenten) auf ihre Tauglichkeit getestet werden. Schließlich ist C# als Antwort auf Java entwickelt worden, nachdem Microsoft mit dem seligen J++ baden gegangen ist. Irgendwo las ich, dass J++ nichts anderes als ein Programmiersprachenexperiment war, um Java auf seine Vor- und Nachteile zu testen. Nun, Microsofties haben es gelernt und .NET ist die Antwort darauf. Aber, nicht nur MS lernt es, Andere tun es ebenfalls. Und Groovy ist so eine Antwort. Jedoch nicht nur auf C#, sondern auf viele andere Sprachen wie z.B. Python und Ruby. Sie alle haben ihre Vorteile und vor allem was Python und Ruby (on Rails) angeht, so sind die beiden Sprachen als wahre Überflieger (oder Hypes?) zu bezeichnen. Nun, Python nicht gerade als Hype, aber Ruby on Rails auf jeden Fall.

Und so ist Groovy entstanden. Als ein natürlicher Evolutionsschritt. Manche sprechen schon davon, dass Groovy eines Tages Java ablösen wird, aber das ist eine andere Liga in der wir hier nicht spielen.

GROOVY KONSOLE

Sehen wir uns man die GroovyConsole an.

GroovyConsole besteht aus zwei Teilen. Im oberen werden die Quellcodes eingegeben und im unteren sieht man die Ergebnisse der Ausführung. Groovy-Codes werden entweder über das Menü “Script” gestartet oder aber durch STRG+R.

Nun geben wir im Edit-Fenster folgenden, hochkomplexen Code ein:

println ‘hello, world’

Ein STRG+R führt das Ganze aus.

Nun, das Kommando ist an sich nichts Neues, würde man sagen. Jedoch ist jeder geübte Java-Programmierer sofort überrascht, wie es zur Ausgabe kommen kann, wo doch die elementarsten Java-Standards nicht eingehalten worden sind. Und Groovy ist doch Java, oder? So gibt es weder Klammern, noch Semikolons und auch keine import-Anweisungen. Nun, Groovy braucht keine Klammern immer und überall, wenn dies nicht nötig ist und Semikolons am Ende einer Befehlsfolge sind kein Muss mehr, sondern nur optional. Wer will, der kann ruhig klammern und Semikolons anwenden. Es ändert sich aber nichts an der Code-Ausführung. Außerdem braucht man folgende Klassen nicht mehr explizit zu importieren, da Groovy dies für uns automatisch erledigt. Selbst das return-Schlüsselwort ist optional (oh, Schreck!..*hihi*)

• java.io.*
• java.lang.*
• java.math.BigDecimal
• java.math.BigInteger
• java.net.*
• java.util.*
• groovy.lang.*
• groovy.util.*

Eine ganze Menge wird da im Hintergrund vorbereitet, ohne dass man dafür irgendetwas tun muss. Groovy heißt nicht ohne Grund “groovy”. Aber dies liegt nicht nur an der Tatsache, dass diese Elemente automatisch mit dabei sind, sondern, dass so mancher Boiler-Plate-Code nicht mehr geschrieben werden muss. Hier ein typisches Beispiel in Java und dann ein in Groovy. Als Java-IDE wird Eclipse 3.3.1.1 benutzt.

Es wird eine simple Klasse JDemo.java mit einer Membervariable und zwei Accessors angelegt. Diese Klasse wird dann von einer anderen JTester.java benutzt, um den Wert der Membervariable zu manipulieren und auszugeben. Wie in Java typisch, werden die beiden Getter- und Setter-Methoden mit einem “get” respektive “set” Präfix versehen.

Und die JTester.java:

Hier ist nichts Besonderes fest zu stellen, da solche Vorgänge in Java x-fach durchgeführt werden. Was hier zu sehen ist, überrascht wirklich niemanden. Es wird eine Klasse instantiiert, einmal die Setter-Methode aufgerufen und ein Wert übergeben. Dieser wird dann auf der Konsole per Getter-Methode getText() ausgegeben.

Schauen wir uns aber dieselbe Implementierung in Groovy mal an.

Zuerst wird eine Klasse GDemo.groovy angelegt die der Klasse JDemo.java entspricht:

Dann wird eine weitere Datei, GTester.groovy, angelegt:

In Groovy-Skripten, wie diesem hier, können Anweisungen ohne eine explizite Klassendefinition stehen. Und wie man unschwer erkennen kann, bediene ich mich hier zweier Accessoren der GDemo-Klasse, ohne dass diese explizit angelegt worden sind. Wie ist das möglich?

Die Antwort auf diese Frage kommt gleich.

COMPILER & SKRIPTE

Sehen wir uns zuerst die ganzen Kompilier- und Skriptvorgänge an.

Bevor diese beiden Quellcodes angewandt werden können, müssen sie natürlich kompiliert werden (ja, auch die Skriptdatei GTester.groovy wird kompiliert). Da Groovy eigentlich Java ist, wäre es sicherlich möglich alles per javac zu erledigen. Da aber dies ein Groovy-Tutorial ist, sehen wir uns mal die Kompilierung mit Groovy an.

Um Kompilieren zu können braucht man entweder einen IDE-Plugin, wie z.B. den für Eclipse, oder aber eine Kommandozeile. Für dieses kleine Beispiel reicht aber die Kommandozeile völlig aus. Um aus GDemo.groovy eine vollwertige Java-Class zu machen, bedarf es folgender Befehlsfolge:

Analog zu javac gibt es also einen Compiler groovyc, welcher mit vorangestelltem Schalter -d die neu kompilierten Klassen in das Verzeichnis classes setzt. Sicherlich kann man auch andere Bezeichnungen für das Class-Verzeichnis wählen, aber classes macht irgendwie am meisten Sinn, oder?

Nachdem die Kompilierung (hoffentlich) fehlerfrei zu Ende gegangen ist, findet man im Verzeichnis classes eine neue Datei:

Damit haben wir die Gewissheit, dass unsere Groovy-Klasse GDemo.groovy von der JVM (Java Virtual Machine) verstanden und ausgeführt werden kann. Jetzt wollen wir die Skriptdatei GTester.groovy benutzen, um auf die Daten von GDemo.groovy zuzugreifen. Und genau an dieser Stelle haben wir es mit einem großen Vorteil von Groovy zu tun, passt gut auf:

Hier wird die eigentlich noch nicht kompilierte Klasse GTester.groovy ausgeführt, indem man einfach so den Interpreter groovy anwendet! Wie geht das denn?

Nun, Groovy war für mich am Anfang auch “nur” eine weitere Skriptsprache, bis ich begriffen habe, wie Groovy vorgeht und was Groovy eigentlich ist. Es dürfte auch jedem klar sein, dass Groovy im Grunde genommen Java ist. Aber nicht nur! Groovy ist auch eine Ansammlung von, nennen wir es, Abkürzungen, welche das Leben eines typischen Java-Programmierers erleichtern. So ist z.B. das Auslesen von Dateien unter Groovy ein Leichtes, da man nicht mehr mit den ganzen Streams und Buffern zu tun hat. Man sagt einfach “gib die Datei aus und zwar zeilenweise” und schon geschieht es, dank der “Abkürzungen”. So ist auch der obige Aufruf auch eine Art Abkürzung, indem man eben nicht explizit kompilieren muss, sondern einfach den Interpreter aufruft und lässig sagt “hier die Datei mit Anweisungen, kümmere dich mal drum, weil ich keine so große Lust habe, den Compiler immer und immer wieder aufzurufen”. Man übergibt den Namen der Datei plus den Pfad zur speziellen Groovy-Klassensammlung und zum class-Pfad wo sich die Klasse GDemo.class befindet. Das ist alles. Und in einer IDE ist es noch wesentlich leichter, da man dort überhaupt nichts mehr sieht. Bis auf die Ergebnisse, natürlich

Der ganze Vorgang des Kompilierens von GTester.groovy (denn es wird schon kompiliert!) läuft völlig transparent ab. Groovy ist nämlich gar keine Skript-Sprache. Groovy tut nur so, indem es den Anschein weckt, dass die ganzen Kommandos in einer Groovy-Datei zeilenweise, ähnlich wie bei BATCH-Files, ausgeführt werden. Dem ist aber nicht so, denn alle Groovy-Dateien werden zuerst kompiliert und dann ausgeführt. Lediglich die Transparenz der Aufrufe (auch eine Anwendung der “Abkürzungsphilosophie”) sorgt dafür, dass man das Gefühl hat, man hätte es hier mit einer Skriptsprache zu tun.

In meinem Beispiel bediente ich mich einer weiteren Umgebungsvariable GROOVY_EMBED. Dies ist zwar keine Vorgabe und ohnehin kein Muss, jedoch erleichtert einem das Arbeiten, wenn man mal in Zukunft eine neue Version von Groovy und seinen Klassen installieren würde. So verweist bei mir GROOVY_EMBED auf den Pfad C:\Programme\Groovy\Groovy-1.5.4\embeddable in welchem sich die aktuelle Version der Groovy-Klassen groovy-all-1.5.4.jar befindet. Bei einer neuen Version müsste man eigentlich nur die Versionsnummer anpassen, da der Rest der gleiche bleibt. Es ist aber jedem selbst überlassen, wie er(sie) dieses erledigt. Und unter einer IDE ist es eh eine Sache von ein paar Klicks unter den Projektoptionen. Es ist aber auf jeden Fall wichtig zu wissen, dass ohne diese Klassen keine skriptähnliche Groovy-Datei kompiliert werden kann.

Schauen wir uns jetzt die Ausgabe des Aufrufs an:

An sich nichts Besonderes wäre da nicht die schon gestellte Frage gewesen, wie es zu dieser Ausgabe kommen konnte, wenn wir in unserer GDemo-Klasse gar keine Getter und Setter Methoden eingetragen haben?

Wie kann man eine Klassenmethode aufrufen, wenn in der Klassendefinition keine angegeben worden ist?

Nun, auch hier gilt der Grundsatz, dass alle Abkürzungen angewandt werden können, sofern diese auch möglich sind. Also braucht man bei Groovy für eine Membervariable keine expliziten Accessoren zu setzen. Vielmehr ist es möglich, im Code der aufrufenden Klasse auch direkt den Variablennamen zu setzen, als ob man direkt die Memebervariable anspricht. Also ist z.B. gdemo.text = “Demo Text” möglich. Dies bedeutet aber nicht, dass wirklich die Memebervariable selbst aufgerufen wird, sondern es handelt sich ebenfalls um eine Abkürzung, die das explizite Anwenden des setText-Accessors unnötig macht. Abkürzungen ohne Ende, nicht wahr?

Das ist aber nicht alles, denn die oben angeführten Zeilenkommandos für die Kompilierung können ebenfalls abgekürzt werden. Ich habe sie aber aus rein pädagogischen Gründen angeführt, denn es macht ja bekanntlich mehr Sinn, wenn man weiß auf was man verzichten kann, als wenn man nicht einmal wüsste, was wichtig ist.

Also ist es auch möglich, beide Dateien GDemo.groovy und GTester.groovy anzulegen und nur den Interpreter groovy auszuführen. Und schon wäre die Klasse GDemo.groovy im Hintergrund kompiliert worden, damit dann das Skript GTester.groovy ordentlich ausgeführt werden kann. Sie glauben es nicht? O.K., hier der Beweis:

Wir löschen die zuvor erstellte Klassendatei GDemo.class und das Verzeichnis classes.

Danach vergewissern wir uns, dass im Verzeichnis gdemo nichts außer den beiden Groovy-Dateien vorhanden ist:

Und jetzt führen wir GTester.groovy mit dem Interpreter groovy aus:

Oh Yes, es funktioniert!

Was passiert denn eigentlich mit GDemo.groovy, wenn wir den Interpreter anweisen, GTester.groovy auszuführen? Nun, da GTester.groovy einige Male auf die GDemo-Klasse zugreift, muss der Interpreter dafür sorgen, dass GDemo.groovy zuerst kompiliert wird, denn ansonsten würde es Fehlermeldungen hageln. Und genau das wird auch im Hintergrund erledigt, bevor GTester.groovy zum Einsatz kommt. Wir haben quasi ein Skript-Feeling inklusive Compiling-Power, ohne aber die ganzen Kommandos selber eingeben zu müssen.

So, damit ist der erste Teil unseres kleinen Tutorials zu Ende. Im nächsten Teil zeige ich, wie mit Groovy problemlos Closures, Listen und Maps angewandt werden können und vielleicht noch ein paar kleine Kniffe mehr…bis dann!