Groovy: Struktur der Groovy-Bibliotheken

Sie werden beim Programmieren mit Groovy öfter einmal in die Situation kommen, eine Klasse für einen speziellen Zweck zu suchen oder sich generell in den Bibliotheken orientieren zu wollen. Wenn Sie einmal einen Blick in die groovy.jar werfen, fällt Ihnen sofort auf, dass die darin befindlichen Packages in zwei Bäume zerfallen. Der eine hat die Wurzel groovy und der andere die Wurzel org.codehaus.groovy.

Grob gesagt, handelt es sich bei den Klassen und Interfaces unter groovy um solche, die für Groovy-Programme in irgendeiner Weise direkt sichtbar sind, sei es als Basisklasse von in Groovy geschriebenen Klassen oder als Klassen, die von Groovy-Programmen verwendet werden. Häufig implementieren sie, auch wenn sie in Java geschrieben sind, das Interface groovy.lang.GroovyObject, können also wie Groovy-Objekte behandelt werden.

Unter org.codehaus.groovy dagegen sind Klassen und Interfaces zu finden, die für die interne Implementierung von Groovy benötigt werden, zum Beispiel für den Groovy-Compiler und für die dynamische Auflösung von Methoden-, Property- und Feldaufrufen. Auf diese Dinge werden Sie in aller Regel als Groovy-Programmierer nicht zugreifen ‒ obwohl dem technisch nichts im Wege steht. Wenn Sie es aus irgendeinem Grunde trotzdem tun möchten, müssen Sie allerdings damit rechnen, dass Ihre Programme nach einem Wechsel auf eine neue Groovy-Version nicht mehr funktionieren, da sich die internen Schnittstellen leicht einmal ändern können.[1]

Wir beschränken uns hier also auf die Packages unter groovy; Folgene Tabelle führt die wesentlichen, darin enthaltenen Packages mit ihrer jeweiligen Bedeutung auf. Außer den Packages groovy.lang und groovy.util, die in Groovy-Programmen standardmäßig verfügbar sind, müssen alle anderen Packages wie üblich importiert werden.

Wichtige Groovy-Standard-Packages
Package Bedeutung
groovy.inspect Enthält den Inspector, mit dem sich alle möglichen Eigenschaften eines Objekts abfragen lassen, sowie ein Skript zur grafischen Anzeige dieser Eigenschaften.
groovy.lang Zentrales Package für alle Typen, die eine grundlegende Bedeutung in Groovy-Programmen haben, analog zum Package java.lang für Java. Die enthaltenen Klassen und Interfaces brauchen nicht importiert zu werden.
groovy.mock Enthält eine Klasse für Mock-Objekte, die zum Testen von Groovy-Klassen verwendet werden können.
groovy.model Verschiedene vorgefertigte Modelle, die bei der Programmierung von nach dem model view controler-Muster gebauten Anwendungsoberflächen angewendet werden können.
groovy.security Enthält eine Permission-Klasse, die für die Zuordnung von Rechten bei Skripten benötigt wird, die keine Codebase im üblichen Sinne besitzen.
groovy.servlet Einige Klassen, mit deren Hilfe Groovy-Skripte und -Templates in Web-Anwendungen verwendet werden können.
groovy.sql Eine API für den vereinfachten Zugriff auf Datenbanken über JDBC mit Groovy-typischen Mitteln.
groovy.swing Enthält den SwingBuilder, mit dem Benutzeroberflächen in einem quasi-deklarativen Stil programmiert werden können.
groovy.text Beherbergt das Template-Framework von Groovy sowie die mit Groovy gelieferten Template-Engines.
groovy.time Einige Klassen für die Arbeit mit Zeiten und Zeitabständen. Derzeit wird noch an einer besseren Unterstützung für Datum und Zeit in Groovy gearbeitet, daher sollten diese Klassen eher nicht verwendet werden.
groovy.ui Alle Klassen, die für den Start von Groovy als Shell oder als Interpreter benötigt werden.
groovy.util Package mit diversen Hilfsklassen, die häufig und für unterschiedliche Zwecke verwendet werden. Die enthaltene Klassen und Interfaces brauchen nicht importiert zu werden.
groovy.xml Klassen, die zur Unterstützung der Arbeit mit XML und HTML dienen.

Auf eine Reihe der in diesen Packages enthaltenen Klassen und Interfaces werden wir im Folgenden näher eingehen; eine Dokumentation der wichtigsten Typen ist außerdem im ##ANHANG## zu finden.


  1. Korrekterweise wollen wir hinzufügen, dass sich auch die anderen Schnittstellen ändern können. Groovy ist eine junge Sprache, und da ist noch einiges in Bewegung. Sie können aber davon ausgehen, dass man bei Änderungen an den Klassen und Interfaces in den Packages unterhalb von groovy sehr viel vorsichtiger sein wird, um vorhandene Programme nicht mehr als nötig zu beeinträchtigen.