Nachdem der ganze Wahnsinn in Sachen immer-schnellere-CPUs-jedes-Jahr an physikalischen Grenzen scheiterte, werden neue (bzw. seit langem bekannte, aber nicht beachtete) Wege beschritten. Joe Armstrong hat in seinem Vortrag bei der Erlang Exchange 2008 über skalierbare Software, Concurrency und Fehlertoleranz gesprochen. Die Slides findet man hier.

Bei der Erlang Exchange 2008 Konferenz wurde das vom Zuse Institut Berlin und onScale Solutions GmbH entwickelte data-store System vorgestellt. Im Vortrag kommen so wichtige Themen wie Distributed Hashtables (DHTs), transaction layer und schnelle application layer für tausendfache Lese-/Schreibzugriffe vor. Weitere Podcasts zum Thema Erlang, fehlertolerante Systeme und Concurrency kann man hier abrufen. Der originale Link zum obigen Podcast ist hier zu finden und die Slides hier.

Als Erstes benötigen wir Emacs, welcher für verschiedene Betriebssysteme bereits vorkompiliert im Netz gefunden werden kann. Ich bevorzuge EmacsW32, wenn ich unter Windows entwickle, aber dies sich ja nur eine Geschmackssache. Auf jeden Fall wird Emacs benötigt.

Danach holen wir uns mit Subversion die Distel-Sourcen:
svn checkout http://distel.googlecode.com/svn/trunk/ distel

Diese Sourcen werden mit “make” kompiliert. Unter Unix/Linux geht dies recht einfach, für Windows muss zuerst die passende POSIX-Umgebung geschaffen werden. Mit Cygwin geht dies am besten und einfachsten. Für alle, die wenig Lust auf Cygwin und die ganzen Compile-Vorgänge haben, gibt es ein Zip-Paket zum Download, welches die ganze Distel-Verzeichnisstruktur beinhaltet (mit bereits kompilierten Dateien). Meine Erlang-Version zum Zeitpunkt der Kompilierung war 5.6.5.

Nachdem Distel-Sourcen übersetzt bzw. heruntergeladen worden sind, sollen diese im Verzeichnis ERLANG_HOME\lib\distel abgelegt werden.

Am Ende solltet ihr eine solche Struktur haben:

Jetzt müssen wir der Erlang-Umgebung einen Pfad mehr verpassen, damit die Distel-Binaries verfügbar sind. Im Verzeichnis ERLANG_HOME\usr wird eine Datei namens .erlang (Punkt nicht vergessen!) angelegt, sofern sie nicht bereits vorhanden ist. Diese erweitert man um folgenden Eintrag

code:add_pathz(“ERLANG_HOME/lib/distel/ebin”).

Jezt passen wir Emacs an und erstellen, sofern nicht vorhanden, eine Datei namens .emacs in eurem Benutzer-Homeverzeichnis. Wenn man sich nicht sicher ist, wie das Homeverzeichnis heißt, einfach auf der Kommandozeile Folgendes eingeben: echo %HOME%

Bei Unix/Linux-Usern schaut das Ganze ein bisserl anders aus.

Dort hilft ein “env” auf der Konsole bzw. echo $HOME.

Im Home-Verzeichnis wird die zuvor erwähnte Datei um folgende Einträge erweitert:

;; Erlang Paths
(setq load-path (cons  “ERLANG_HOME/lib/tools-2.6.2/emacs” load-path))
(setq erlang-root-dir “ERLANG_HOME“)
(setq exec-path (cons “ERLANG_HOME/bin” exec-path))
(require ‘erlang-start)

;; This is needed for Distel setup
(let ((distel-dir “ERLANG_HOME/lib/distel/elisp”))
(unless (member distel-dir load-path)
;; Add distel-dir to the end of load-path
(setq load-path (append load-path (list distel-dir)))))
(require ‘distel)
(distel-setup)

;; Some Erlang customizations
(add-hook ‘erlang-mode-hook
(lambda ()
;; when starting an Erlang shell in Emacs, default in the node name
(setq inferior-erlang-machine-options ‘(“-sname” “emacs”))
;; add Erlang functions to an imenu menu
(imenu-add-to-menubar “imenu”)))

;; A number of the erlang-extended-mode key bindings are useful in the shell too
(defconst distel-shell-keys
‘((“\C-\M-i”   erl-complete)
(“\M-?”      erl-complete)
(“\M-.”      erl-find-source-under-point)
(“\M-,”      erl-find-source-unwind)
(“\M-*”      erl-find-source-unwind))
;; Additional keys to bind when in Erlang shell.”)
(add-hook ‘erlang-shell-mode-hook
(lambda ()
;; add some Distel bindings to the Erlang shell
(dolist (spec distel-shell-keys)
(define-key erlang-shell-mode-map (car spec) (cadr spec)))))

Ein Beispiel für ERLANG_HOME wäre C:/Programme/erl5.6.5

Und auch für diesen Schritt habe ich ein entsprechendes Download vorbereitet, falls man doch wenig Lust hat, sich in die Emacs-Lisp-Syntax einzuarbeiten.

Jedoch sollten die Pfade angepasst werden und auch muss man daraus achten, dass die eventuell vorhandenen Leerzeilen in Windows Pfaden umgangen werden.

Jetzt können wir Emacs starten und sich mit dem neue Erlang-Modus vertraut machen. Um diesen zu aktivieren, muss eine *.erl-Datei geladen werden.

Daneben ist noch ein weiteres Menü namens imenu vorhanden, welches vor allem bei umfangreichen Quellcodes recht nützlich ist, da es sämtliche Funktionen auflistet, die aktuell vorhanden sind. Diese kann man dann direkt ansteuern. Um eine Erlang-Shell zu starten, wählt man den Menüpunkt Shell/Start New Shell aus.

Als Ergebnis erhält man automatisch eine neue Shell innerhalb der Emacs-Umgebung.

In dieser kann man z.B. die über Emacs kompilierten Erlang-Quellcodes starten. Würden wir den angezeigten Code kompilieren wollen, so wäre die Vorgehensweise wie folgt:

Übrigens: das Wechseln zwischen verschiedenen “Buffers”, denn auch eine Erlang-Shell in Emacs ist “nur” ein weiterer Buffer, geschieht über den Menüpunkt “Buffers”. Dort wählt man einfach den gewünschten Buffer aus (hier den Quellcode) und anschließend startet man das Kompilieren desselben über Erlang/Compile/Compile Buffer. Wenn alles ordentlich verlaufen ist, erhält man folgendes Ergebnis:

Es wird also die zuvor geöffnete Shell benutzt, um den Quellcode zu kompilieren. Hätten wir keine Shell zuvor aufgemacht, so würde Emacs automatisch eine entsprechende starten. Jetzt können wir auch direkt in derselben Shell das Kompilat starten:

Dies wäre ein typischer Vorgang beim Entwickeln unter Emacs/Distel. Zuerst den Code im Buffer eingeben (oder Teile davon) und dann schrittweise testen. Ferner bietet Distel auch die Möglichkeit an, bestimmte Code-Skeletons automatisch einzufügen. Hier ein Beispiel mit einem einfachen Server-Skeleton:

Ein weiteres, äußerst nützliches Feature von Distel ist die Debugging-Funktionalität. Um diese zu nützen benötigt man neben einem geladenen Quellcode auch eine laufende Erlang-Shell. Sind diese vorhanden, wird aus dem Quellcode-Buffer (dieser muss über Buffer-Menü gewählt werden!)  eine Connection zur bereits gestarteten Shell aufgebaut. Dazu bedient man sich des folgenden Menüpunktes:

Es ist natürlich auch möglich, all diese Optionen direkt über Tasktenkombinationen auszuwählen.

Direkt nachdem wir die Option aktiviert haben, werden wir nach dem Namen des Erlang-Nodes gefragt, welcher in der unten eingeblendeten Zeile eingegeben werden muss. Der Node-Name setzt sich immer aus Node-Name@Maschinen-Name zusammen. Am einfachsten ist es, sich über das Buffer-Menü zu vergewissern wie der Node heißt. Und falls wir mehrere haben, wählt man einen aus.

Nachdem der Node konnektiert wurde, muss natürlich der Quellcode kompiliert werden, damit das Debugging auch einen Sinn macht. Jedoch werden wir diesmal nicht den Menüpunk Erlang/Compile/Compile Buffer wählen, sondern direkt über die Erlang-Shell kompilieren. Dies hat damit zu tun, dass wir für das Debugging zusätzliche Informationen in unserem Kompilat bereitstellen müssen (sog. Debug-Infos). Deswegen brauchen wird einen leicht erweiterten Kommandoaufruf in der Zeile. Wir wählen also die Erlang-Shell und geben Folgendes ein (“func1″ wird natürlich nicht immer vorkommen müssen, sondern der Name eurer *.erl-Datei):

Danach müss das fertig kompilierte Modul neu geladen werden. Dies erfolgt über folgenden Menüpunkt:

Und auch hier muss der Name des Moduls in unten eingeblendeter Zeile eingegeben werden. Standardmäßig wird das aktuell kompilierte Modul vorgeschlagen, sodass man diesen nur noch bestätigen muss. Ist alles erfolgreich verlaufen, wird in der Zeile folgende Nachricht angezeigt (mit entsprechendem Modulnamen):

Jetzt aktivieren wir das Debugging:

Ist alles gut verlaufen, meldet sich Emacs mit folgender Meldung zurück:

Danach können wir in unserem Quellcode z.B. einen Breakpoint setzen, welcher dann zur Laufzeit die Abarbeitung anhalten wird. Dazu setzen wird den Cursor an die gewünschte Position und wählen diesen Menüpunkt aus:

Automatisch wird die ausgesuchte Zeile rot markiert. Will man den Breakpoint entfernen, muss nur derselbe Menüpunkt gewählt werden (oder, wie immer, die passende Tastenkombination eingegeben werden).

Jetzt rufen wir die markierte Funktion in der Erlang-Shell auf. Direkt nachdem sie gestartet wurde, wird ein neuer Debug-Buffer aktiviert, in welchem die Infos zu unserem Breakpoint und seiner momentanen Ausführung aufgelistet sind.

Man sieht unten, dass noch kein Ergebnis der Funktion double(12) zurückgegeben worden ist. Dies ist ein Zeichen, dass die weitere Ausführung ab jetzt auch schrittweise erfolgen kann. Um den angezeiten Prozess manuell zu debuggen, positioniert man den Cursor auf die gewünschte Zeile (in diesemFalle ist es nur eine, was aber nicht immer sein muss). Dann drück man einmal auf ENTER und automatisch wechselt Emacs zum Quellcode genau an die Stelle wo das Debugging markiert wurde. Man erkennt es auch am grünen Pfeil direkt neben der Quellcode-Zeile. In der unteren Fensterhälfte sieht man den momentanen Status der eingesetzten Variablen (in diesem Falle ist X = 12, was unserer Eingabe beim Funktionsaufruf entspricht).

Jetzt hat man die Wahl zwischen diesen Optionen, welche über die Tastatur eingegeben werden:

• h: Anzeige verfügbarer Kommandos.
• q: Debug-Anzeige beenden (der gedebuggte Prozess wird aber nicht geschlossen)
• SPC: Nächster Schritt.
• n: Über den Ausdruck hinausgehen.
• u: Nach oben zum nächsten Stack-Frame.
• d: Nach unten zum nächsten Stack-Frame.
• c: Fortsetzen bis zum (eventuell) nächsten Breakpoint.
• b: Breakpoint auf der aktuellen Zeile setzen/entfernen.

Man sieht, dass eine schnelle und komfortable Entwicklung auch mit Erlang möglich ist.

Viel Spaß mit Erlang, Emacs & Distel!

Gegeben ist folgender Quellcode, welcher ein Programm zum Berechnen des Quadrats einer beliebigen Zahl bildet:

Das Programm besteht aus zwei Teilen, den Modulattributen und Funktionen.
Modulattribute sind in diesem Falle -module(func1) und -export([double/1]).

Modulattributen können sowohl vom Entwickler selbst definiert, wie auch aus einem Satz von Standardvorgaben eingesetzt werden.
Die Attribute -module und -export gehören zum Erlang-Standard, wobei -module zwingend ist, während -export nur dann eingesetzt werden sollte, wenn man bestimmte Funktionen für den Zugriff von Außen freigeben möchte. In diesem Falle ist es die Funktion double, die z.B. von der Erlang-Shell aus aufgerufen werden soll. Jede Erlang-Quelldatei muss eine Angabe über den aktuellen Modulnamen tragen und zwar innerhalb der Klammern des Attributen -module. Somit ist der Name der *.erl-Datei gleichzeitig auch der Name des Moduls. Nachdem dieses beispielsweise über den Aufruf c(MODULNAME). in der Shell kompiliert worden ist, wird eine neue Bytecode-Datei namens MODULNAME.beam angelegt. Und genau diese ist für die eigentliche Ausführung in der Erlang Virtual Machine gedacht. Dies ist mit Java *.class-Dateien vergleichbar, die aus gewöhnlichen *.java-Dateien gebildet werden, um dann in der JVM als Bytecode ausgeführt zu werden. Und wie bei sonstigen Erlang-Anweisungen auch, müssen diese beiden Attribute mit einem Punkt abgeschlossen werden.

Jedoch sollte noch geklärt werden, was die Angabe [double/1] zu bedeuten hat. Nun, da Funktionen mehrere Argumente akzeptieren können und in mehrfacher Ausführung vorhanden sein dürfen (d.h. mit gleichem Funktionsnamen, jedoch unterschiedlicher Anzahl von erwarteten Argumenten), ist die Angabe des Funktionsnames zusammen mit Slash + Zahl für die Anzeige der “Stelligkeit” (engl. “Arity”) einer Funktion notwendig. Mit “Stelligkeit” ist hier die Anzahl der “erwarteten Argumenten-Stellen” gemeint. Da unsere double-Funktion nur ein Argument erwartet, nämlich X, ist ihre Stelligkeit “eins” (1). Hätten wir z.B. weitere double-Funktionen, so müssten sich diese in der Stelligkeit voneinander unterscheiden, um von Erlang akzeptiert zu werden.

Nachdem wir mit Attributen dem Compiler die Umgebung vorgestellt haben, widmen wir uns der Funktion double. Sie besteht, nach Erlang-Terminologie, aus einem Headund einem Body. Zwischen diesen befindet sich ein stilisierter Pfeil, der vom Head auf den Body zeigt. Der Head ist dabei immer mit einem Funktionsnamen gefolgt von einem Klammerpaar und (optional) mit einer Argumentenliste innerhalb dieser versehen. Dabei werden mehrere Argumente durch Kommata voeinander getrennt. Als Argumente können sowohl Variablen wie auch Atome eingesetzt werden. Mit “Atome” sind konstante, nicht-numerische Werte gemeint, welche immer mit einem Kleinbuchstaben beginnen (im Gegensatz zu Variablen, welche immer mit einem Großbuchstaben anfangen). In unserem Falle kann double einen beliebigen Wert annehmen, welcher dann im Body mit sich selbst multipliziert wird. Und auch hier ist am Ende ein Punkt zu setzen.

Die Kompilierung des Programms ist denkbar einfach: Erlang-Shell starten und mit c(func1). die func1.erl-Datei kompilieren. Als Ergebnis erhält man ein sog. Tupel, welches aus dem Namen des Moduls und einem Atom “ok” besteht. Somit hat uns Erlang-Umgebung die Info geliefert, dass die Kompilierung erfolgreich verlaufen ist.

Da ich lokal das Ganze über Emacs laufen lasse, schaut bei mir die Ausgabe vielleicht etwas komplexer aus, als sie vielleicht sein sollte. Dennoch ist die Vorgehensweise dieselbe.

Jetzt können wir die exportierte Funktion double aufrufen. Dabei übergeben wir ihr den erwarteten Zahlenwert.

Als Ergebnis erhalten wir 144, was dem Quadrat von 12 entspricht. Der Aufruf selber ist recht einfach und erinnert entfernt an das Programmieren in C++, wenn es darum geht, die einzelnen Methoden den passenden Klassen/Namespaces zuzuordnen. In C++ wird die Zuordnung über sog. “Bereichsauflösungsoperatoren” erledigt (d.h. mit KLASSE::METHODE). Ähnlich wird auch bei Erlang verfahren, z.B. wenn es darum geht, die passende Funktion eines Moduls aufzurufen. Da es wohl recht viele “double”-Funktionen geben darf, muss sichergestellt werden, dass sowohl die richtige aufgerufen, wie auch die passende “Stelligkeit” befolgt wird. Es sind also zwei Sachen zu beachten: die passende Funktion über (optional viele) Module hinweg und dann noch die Funktion mit der gewünschten Stelligkeit (“Arity”) innerhalb eines Moduls. Hier ein leicht erweitertes Beispiel mit unserem bisherigen Modul.

Jetzt beinhaltet unser Modul eine weitere Version der double-Funktion. Diesmal ohne Argumente, d.h. mit Stelligkeit Null (0). Über diese Änderung muss auch der Compiler informiert werden, sofern wir vor haben, eine weitere Funktion zu exportieren. Daher wird die Liste in -export um einen Eintrag mehr erweitert. Die Listen werden in Erlang übrigens immer mit eckigen Klammern angegeben und ihre Elemente durch Kommata voneinander getrennt. In diesem Falle wäre es [double/0,double/1]. Nachdem wir die neue Modulversion kompiliert haben (in der unteren Fensterhälfte zu sehen), wird die neue double-Funktion aufgerufen (diesmal mit leeren Klammern, aber immer zusammen mit dem Modulnamen). Als Ergebnis erhält man 4, was genau den Vorgaben im Funktions-Body entspricht. So einfach kann Erlang sein.

Das ist aber nicht alles, denn in Erlang können Funktionen mehr als nur Werte zurückgeben und in mehrfacher Ausführung gleichzeitig vorhanden sein. In Erlang können Funktionen auch neue Funktionen als Ergebnis zurückgeben.

Noch einmal, zur Wiederholung: Funktionen können in Erlang neue Funktionen als Ergebnis zurückgeben. Oder Erlang-like ausgedrückt: wir können “higher-order-functions” basteln.

Hier ein kleines Beispiel:

Wir haben eine Variable Multiply, welche keinen direkten Wert zugewiesen bekommt, sondern vielmehr ein zunächst sonderbares Konstrukt:

fun(X,Y) -> 3 * (X + Y) end.

Was meint man damit?

Nun, die Bezeichnung fun habe ich mir, schon mal im Voraus, nicht ausgedacht, denn diese gehört zum Sprachumfang von Erlang. Dabei meinen wir mit dem Einsatz von fun, dass hier eine neue Funktion mit 3 * (X + Y) end. aufgebaut werden sollte. Dies bedeutet, dass wir in fun(X,Y) die Elemente eingesetzt haben wollen, welche später (im Funktions-Body) an die Stellen zum Einsatz kommen werden, wo jetzt 3 * (X + Y) end. steht, um einen neuen Wert zu berechnen. Somit steht Multiply stellvertretend für eine dahinter “eingebettete” Funktion, welche eben zwei Werte erwartet und nach einem bestimmten Algorithmus (hier: 3 * (X + Y)) rechnet. Diese “innere” Funktion wird auch durch das spezielle Schlüsselword end. auch explizit beendet. Ein fun wird immer mit einem end. abgeschlossen, damit Erlang diese richtig zuordnen und bei Bedarf auch “als Rückgabe-Wert” liefern kann.

Deshalb ist die Shell-Info beim ersten, oben abgebildeten Aufruf eben kein berechneter Wert, sondern vielmehr eine Erlang-Info die mit #Fun<erl_eval anfängt. Diese recht kryptische Ausgabe sollte aber niemanden verwirren, denn es handelt sich nur um Erlang-Internals, die für die Entwicklung selbst unerheblich sind. Wichtig ist nur zu wissen, dass damit Erlang zu verstehen gibt, dass es die Vorgaben evaluiert hat und in Zukunft überall dort wo Multiply steht eben diesen Algorithmus aktivieren wird. Ein simples Aufrufen von Multiply(3,3) gibt 18 aus und somit ist die Abarbeitung erfolgreich verlaufen. Für alle Entwickler die schon mal mit anonymen Funktionen zu tun hatten: “ja, dies sind anonyme Funktionen in Erlang“, was an sich kein Wunder ist, da anonyme Funktionen aus der funktionalen Programmierung kommen und Erlang eben “so ziemlich” funktional ist.

Dies ist aber auch nicht alles, denn mit funs kann man noch viel mehr machen, wie in diesem Beispiel hier:

Hier haben wir einen weiteren Level-Of-Indirection eingebaut und eine fun deklariert, die wiederum eine weitere fun beinhaltet. Um die Verwirrung aber schon zu Anfang zu ersticken, fangen wir ganz langsam an und schauen uns die einzelnen Bestandteile genauer an:

MoreMultiply bekommt Folgendes zugewiesen: fun(HowMuch) -> (EINE WEITERE FUN EINGEBETTET)

Wie wir schon im ersten Beispiel erfahren haben, können Variablen eingebettete funs beinhalten. Hier aber befindet sich aber in der ersten fun fun(HowMuch) eine weitere fun, welche wir aus Gründen der Übersichtlichkeit nicht aufgeschrieben haben.

Was hat dies zu bedeuten?

Ganz einfach: die erste fun (nennen wir diese “die äußere”) erwartet ein Argument, welcher dann in der zweiten (der “inneren”) fun eingebettet wird. Die innere fun beinhaltet aber mehr als nur die Variable HowMuch, nämlich Value * HowMuch. Dies bedeutet, dass die innere fun erst gar nicht rechnen könnte, wenn die äußere fun keinen Wert an sie liefern würde. Und genau hier liegt die Bedeutung in dieser scheinbar unnötig komplexen Verzahnung. Die innere fun ist nämlich eine VERALLGEMEINERTE Ausführung eines einfachen Multiplikators, welcher aber eben nicht selber vorgibt, wie eines seiner Elemente multipliziert wird. Die SPEZIALISIERUNG also, in diesem Falle die Angabe HowMuch kommt aus der äußeren fun. Somit ist die Arbeitsteilung klar: die äußere fun sagt, wer der Multiplikator ist und die innere benutzt diesen dann, um kommende Werte (d.h. Value) mit ihm zu multiplizieren. Deshalb ist der Rückgabewert von MoreMultiply eben nicht ein berechnter Wert, sondern vielmehr eine der vielen möglichen Spezialisierungen der inneren fun. Und erst mit dieser zurückgegebenen Spezialisierung können Berechnungen durchgeführt werden. So wie im Beispiel oben. Und auch hier meldet sich zuerst die Erlang-Shell und gibt die Erfolgsmeldung aus, dass die Evaluierung OK sei. Danach weisen wir einer neuen Variable die von uns gewünschte Spezialisierung zu (der Name der Variable sollte sinnvollerweise die Spezialisierung dokumentieren). In diesem Falle haben wir uns entschieden, dass die innere fun alle zukünftigen Werte mal 2 nehmen soll. Daher auch die Angabe MoreMultiply(2). Jetzt können wir die in MakeDouble abgelegte (innere) fun anwenden und geben eine 5 ein. Das Ergebnis ist erst jetzt mathematischer Natur und heißt 10.

Eigentlich einfach, nur es braucht Zeit, bis man sich vom alltäglichen Schema WERTEINGABE -> BERECHNUNG -> AUSGABE befreit hat. Hier wird eben ALGORITHMUSAUFBAU -> WERTEINGABE -> BERECHNUNG -> AUSGABE angewandt. Wir basteln uns zuerst den Algorithmus zusammen und setzen ihn erst später ein. Fast so wie mit Möbeln bei Ikea

So, das war’s für heute. Viel Spaß mit Erlang.

Recently, I’ve heard a lot about Erlang, especially from curious members of the Ruby community. This article is the result of my quick dive into the language, and will hopefully serve as a starting point for anyone else who’s been hearing the buzz, but hasn’t taken the plunge yet.

ONLAMP TUTORIAL

Um den Schrecken aber nicht allzu sehr zu steigern (denn schließlich sollen ja paar Leute dieses Tutorial lesen), kümmern wir uns erst einmal um die Einrichtung der Erlang-Umgebung. Vergleichbar mit der JVM für Java oder .NET für C#, muss auch für Erlang bestimmte Vorarbeit geleistet werden, um an die Sprache (und den ganzen Rest) ranzukommen. Denn Erlang ist nicht nur eine Sprache, sondern auch eine Laufzeitumgebung (so ähnlich wie JVM oder .NET) wie auch eine Bibliothek. Da diese Dreigliedrigkeit aber eine recht hohe Komplexität in sich birgt, werden wir uns Schritt für Schritt der Programmiersprache Erlang nähern und mittels Erlang-Shell die Laufzeitumgebung Erlang kennenlernen, wie auch die Erlang-Bibliothek.

Die erste Anlaufstelle für Erlang/OTP is www.erlang.org (ja, eigentlich heißt es nicht bloß “Erlang”, sondern immer Erlang/OTP…Erklärung kommt später noch). Dort geht man auf Downloads und lädt sich die entsprechenden Binaries (es gibt sie für verschiedene Systeme, in diesem Tutorial wird Win32-Version eingesetzt). Die Installation wird per Installer durchgeführt und bereitet keinerlei Schwierigkeiten. Wer auf Linux-Version setzt, kann z.B. unter Debian (oder auch Ubuntu) mit einem einfachen apt-get install erlang die ganzen Binaries holen. Wer zuerst das ganze System lokal kompiliert haben möchte, muss mehrere Schritte gehen:

$ tar -xzf otp_src_R12B-4.tar.gz
$ cd otp_src_R12B-4
$ ./configure
$ make
$ sudo make install

Bei der Installation unter Windows wird man folgendes Fenster zu sehen bekommen:

Erlang-Installer erkennt automatisch, ob bestimmte DLLs bereits unter Windows vorhanden sind.

Danach geht es weiter zum Einrichten des Install-Verzeichnisses.

Noch den Menüeintrag setzen und mit der Installation kann begonnen werde.

Die wichtigste Schnittstelle zu Erlang ist sicherlich die Erlang-Shell, welche von der Kommandozeile aus per erl.exe aufgerfuen wird. Es existiert auch eine eigenständige Shell-Applikation, die über Windows-Menüs aufgerufen werden kann (werl.exe). Um ein ordentliches Arbeiten innerhalb der DOS-Konsole zu gewährleisten, sollte die PATH-Variable unter Windows um den Pfad zum Erlang-BIN-Verzeichnis gesetzt werden (z.B. C:/Programme/erl5.6.4/bin).

Wie man unschwer erkennen kann, ist meine Shell etwas “gesprächiger” als erwartet, da hier einige Verzeichnisse zusätzlich ausgegeben wurden. Dies liegt an der Anpassung einer speziellen .erlang Datei aus dem usr-Verzeichnis der Erlang-Installation. Diese Datei benutze ich vor allem, um eigene Quellcode-Verzeichnisse der Erlang-Shell bekannt zu machen. So muss ich dann bei der Kompilierung von der Shell aus keine langen Pfadangaben machen. Zusätzlich habe ich der .erlang-Datei die Pfadangabe einiger Emacs-Module angehängt (diese werden aber jetzt (noch) übersprungen). Erlang ist schon ungewöhnlich genug. Wenn ich jetzt noch mit Emacs anfangen würde, dann würde das Tutorial wirklich niemand mehr lesen wollen

Eine mögliche .erlang-Datei könnte bspw. so ausschauen:

io:format(“Lese .erlang aus ~p~n~n”,
[element(2, file:get_cwd())]).
% Erlang Code Path
io:format(“Wechsle ins “).
c:cd(“K:/desk/eigene/Codes/erlang”).
io:format(“\nQuellcodes sind in ~p~n~n”, [element(2, file:get_cwd())]).

Hier wird eine Ausgabe getätigt (io:format) inklusive der Information zum Verzeichnis, in welchem sich .erlang befindet (file:get_cwd()).  Danach wechselt die Shell mit c:cd() ins Quellcode-Verzeichnis und gibt wieder eine Information per io:format aus. Wie man merkt, sind einige der Sachen schon “bekannt” und erinnern sehr stark an bekannte DOS oder POSIX-Kommandos. Dennoch werden wir nicht von diesen Befehlen aus die Sprache Erlang anfassen und widmen uns lieber der Shell und ihren Besonderheiten. Denn, wer Erlang programmieren will, der macht es zuerst über die Shell. Es bringt bei Erlang wirklich nicht viel, wenn man sich auf irgendwelche Codes stürzt, diese schnell “mal eben” in irgendeinen Editor eingibt und dann versucht zu kompilieren. Erstens, es würde nicht einfach so gehen, denn selbst der Erlang-Compiler will von der Shell aus bedient werden (zumindest für den Anfang) und zweitens ist Erlang an einigen Stellen derart besonders, dass diese abgetippten Programme eh nicht verstanden werden könnten, selbst wenn sie zum Laufen gebracht worden wären. Also, ab zur Shell, ein paar Befehle eingeben:

So, in der ersten Zeile haben wir 10 + 100, dann eine weitere Zeile mit einem Punkt und dann dahinter das Ergebnis 110. Was hat das zu bedeuten? Ganz einfach zwei Dinge: in Erlang kann man direkt rechnen, ohne viele Umwege (also nix da mit int x = 10; int y = 100; int ergebnis = x + y;). Und was die Befehlsfolge angeht, so muss jede Anweisung mit einem Punkt enden, damit sie auch richtig interpretiert werden kann. Daher tat die Maschine nichts, als wir 100 eingegeben haben, denn es gab (noch) keinen Abschlusspunkt! Beim zweiten Versuch mit gleichen Operanden sehen wir, dass es sofort zum Ergebnis kommt. Das ist aber noch nicht die Welt und an sich auch keine Überraschung, denn auch andere Sprachen können “sowas”

Übrigens, vorangegangene Befehle können in der Erlang-Shell einfach mit den Pfeiltasten wieder hervorgeholt werden.  Oder aber mit Emacs-Befehlen (CTRL+P, CTRL+N). Im Allgemeinen ist das Editorsystem Emacs sehr empfehlenswert, wenn man mit Erlang zu tun hat. So existieren einige sehr gute Module für Erlang (mit Debugging-Möglichkeiten, Shell-Integration etc.). Jedoch kann z.Zt. auf Emacs verzichtet werden, da wir noch lernen, mit Erlang zu gehen. Fliegen werden wir (hoffentlich) später. Jetzt geben wir Folgendes in Erlang ein und tauchen so langsam in die seltsame Welt ein:

Wie wir sehen, muss bei Variablendeklaration kein expliziter Datentyp angegeben werden. Denn Erlang ist eine dynamisch getypte Sprache und somit entfällt das Vorgeben der zu erwarteten Datentypen.  Jedoch ist dies nicht die ganze Wahrheit, denn passt jetzt auf, was passiert, wenn man versucht, der angeblichen “Variablen” VariableX einen neuen Wert zuzuweisen.

Da meldet sich die Shell mit der Info, dass Werte nicht übereinstimmen! Aber, wir wollten doch nicht vergleichen, sondern zuweisen. Was ist denn hier passiert? Eigentlich ist die Erklärung ganz einfach zu verstehen, es sei den, man hat ein Leben lang nur mit “gewöhnlichen” Sprachen zu tun gehabt. Also, das Gleichheitszeichen ist kein Zuweisungsoperator, nicht einmal beim ersten Male, als VariableX = 10. stand. Nein, es gibt keine eigentlichen Zuweisungen in Erlang, denn auch die VariableX ist keine Variable, da man ihren Wert nicht wie bei vielen anderen Sprachen beliebig ändern kann. Vielmehr ist Erlang beim Interpretieren von Anweisungen an “Pattern Matching” angelehnt. D.h., dass beim ersten Male die Shell eben den Wert auf der rechten Seite (10) dem Pattern VariableX gleichgesetzt hat (oder in der Erlang-Terminologie “variable was bound“). In Erlang gibt es also nur gebundene und ungebundene Variablen. Alles andere entfällt. Deshalb gab es auch beim zweiten Versuch eine Fehlermeldung, weil eine gebundene Variable vor einen neuen Wert gesetzt wurde und gemäß Pattern Matching dieser Ausdruck als unwahr zu gelten hatte. Und das ist wiederum der Grund für die auf den ersten Blick seltsame Fehlermeldung, die besagt, dass der rechtsseitige Wert keine Entsprechung auf der linken Seite hatte. Dies ist sicherlich eine der wichtigsten (und wohl auch ungewöhnlichsten) Eigenschaften von Erlang. Variablen sind nämlich viel mehr den mathematischen Variablen ähnlich (so wie wir es eben in der Schule gelernt haben) und Operatoren wie das Gleichheitszeichen sind wirklich zum Vergleichen da und nicht für die gewohnte Wertezuweisung. Also, verkürzt: es gibt nur ungebundene und gebundene Variablen und alles wird per Pattern-Matching (Musterüberprüfung) erledigt. Und da Mathematik in ihrer abstraktesten Definition nichts anderes als die “Wissenschaft von Mustern” sei, ist es wohl mehr als logisch, dass mathematisch-orientierte Erlang-Variablen eben nach “Musterüberprüfung” verarbeitet werden und nicht durch stumpfe Wertezuweisung. In der Tat ist jede Erlang-Variable nichts anderes als ein gewöhnliches Pattern (“Muster”) und dementsprechend geht der Erlang-Interpreter so vor, wenn er zum ersten Mal auf einen Ausdruck wie z.B. VariableX = 10. stößt:

MUSTER “VariableX” erkannt, jedoch ist “VariableX” noch UNGEBUNDEN.

Setze MUSTER “VariableX” in VERBINDUNG zu 10, weil ein GLEICHHEITSZEICHEN zwischen diesen beiden steht.

Kommt es später zu einem neuen Pattern wie VariableX = 200., gibt es sofort eine Fehlermeldung, da eben das zuvor erkannte Muster nicht mehr auf diesem neuen abgebildet werden kann. Würdet ihr jetzt aber noch einmal VariableX = 10. eingeben, so gäbe es keine Fehlermeldung, sondern bloß die Ausgabe 10. D.h. das erste Muster ist als wahr erkannt worden.

So, das wär’s dann für’s Erste und ich hoffe, dass ein paar von euch dabei geblieben sind und tatsächlich diese abschließenden Worte lesen. Ganz zu Anfang dieses ersten Tutorials versprach ich zu erklären, was Erlang/OTP bedeutet. Ganz einfach: OTP steht für “The Open Telecommunication Platform” und stammt aus den Laboren der Firma Ericsson, welche auch die Sprache Erlang entwickelt hat. OTP ist eine spezielle Middleware mit dem Fokus auf den Aufbau von verteilten, hochverfügbaren Systemen. Dies bedeutet, dass Erlang zu Anfang für kommerzielle Projekte eingesetzt wurde. Erst später ist die Sprache zum OpenSource erklärt worden. Somit ist Erlang eine der wenigen Sprachen, die in einer kontrollierten Umgebung entwickelt, später dann bei einem internationalen Konzern auf “Herz und Nieren” geprüft (vor allem was Skalierbarkeit, Geschwindigkeit und Concurrency angeht) und erst danach in die OpenSource-Hände übergeben wurde.

Der Name “Erlang” selbst ist zu Ehren des Wissenschaftlers Agner Krarup Erlang als Bezeichner für die Sprache gewählt worden (auch wenn die Ähnlichkeit zu “Ericsson Language” nicht von der Hand zu weisen ist).

Weiterführende Informationen:

http://www.erlang.org/doc/getting_started/part_frame.html

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!