© lama-photography, Photocase.com

Eine Träne des Abschieds tupfe ich aus einem Augenwinkel. Es ist auch eine Träne der Scham über den Verrat, den ich begehen soll. Viele Jahre haben mir Emacs und Vi, Grep und Find, Etags und Perl-Skripte treue Dienste geleistet für die Programme, die ich schrieb. Jetzt wage ich den Umstieg zu Eclipse [1].

Eine integrierte Entwicklungsoberfläche soll eine Menge Vorteile bieten. Sie verbindet Abläufe unter einer Arbeitsfläche, kann tiefer in meinen Code hineinblicken und Zusatzwerkzeuge in einheitlicher Weise einbinden. Auf der anderen Seite fürchte ich die Kontrolle zu verlieren über meiner Dateien und Tools, manifestiert sich doch durch sie meine archetypische Unix-Erfahrung.

Zum Test verwende ich Eclipse auf einer frischen Installation von Kubuntu 10.04 aus den offiziellen Paket-Repositorys. Der Aufruf »aptitude install eclipse« holt mir die Version 3.5.2 Galileo auf den Rechner mit seiner 3,0 GHz getakteten Pentium-4-CPU und 2 GByte Hauptspeicher. Zusammen mit Galileo landen gleich 120 weitere Pakete auf meiner Festplatte an, die seitdem 465 MByte dort belegen. Eclipse selbst liegt fast ausnahmslos unterhalb von »/usr/lib/eclipse«, sodass die Installation auf mich einen aufgeräumten Eindruck macht.

Eclipse gilt in erster Linie als Entwicklungsumgebung für Java. Also stecke ich mir als erstes Ziel, den Code für eine Hello-World-Anwendung zu schreiben, zu übersetzen und auszuführen. Bislang tippte ich kurze Quelltexte wie Listing 1 auch schon einmal mit »cat > Hello.java« oder in einem vernünftigen Editor ein, übersetze ihn mit »javac Hello.java« und starte das so entstandene Class-File mit »java Hello«.

01 package de.linuxnewmedia.hello.one;
02 class Hello {
03 
04     public static void main(String[] args) {
05         System.out.println("Hello, World!");
06     }
07 }

In Eclipse funktioniert das ganz anders, wie ich schnell feststelle. Wohltuenderweise gibt es nur ein einziges ausführbares Programm, das sich von der Kommandozeile, unabhängig vom aktuellen Arbeitsverzeichnis, mittels »eclipse« oder durch Klick auf ein entsprechendes Icon oder Menü starten lässt. Die Dokumentation hatte mir verraten, dass die IDE in der Voreinstellung nach etwa 256 MByte Hauptspeicher verlangt, und tatsächlich messe ich einen Verbrauchswert in dieser Größenordnung.

Vokabeln trainieren

Bevor ich überhaupt die ersten Schritte machen kann, muss ich erst einmal auf die Schulbank: Vokabeltraining steht auf dem Stundenplan. Eclipse kennt viele Begriffe, die zwar sehr plausibel klingen, die ich aber intuitiv nicht genau einordnen kann: Was ist jetzt doch gleich ein Part, was ein View oder eine Resource? Worin unterschieden sich Workbench, Working Set oder Workspace genau? Ist ein Project Teil einer Resource oder war das andersherum?

Die Begrifflichkeit ist am Anfang die größte Hürde. Wer glaubt, dass sich Anwendungen nur wegen ihrer Mausbedienung automatisch ohne Dokumentation oder gar intuitiv steuern lassen, ist auf dem Holzweg. Ich beklage mich aber nicht über Gebühr, denn die mitgelieferte Dokumentation erfasst viele Einsatzbereiche. Ihr profunder Umfang behindert mich mitunter, denn er erschwert mir, aus der Fülle der Angebote die Antworten auf sich stellende Fragen zu finden. Der über die Hilfefunktion integrierte “Workbench User Guide” leitet mich aber über die ersten Hürden und erklärt die Oberfläche. Ergänzend dazu gibt es den “Java Development User Guide” für die Java-spezifischen Fragestellungen.

Nach der Arbeitsplatzwahl gibtsWillkommensgrüße

Die Anleitungen erklären mir, dass ein Workspace ein Unterverzeichnis ist, in dem Eclipse sämtliche Einstellungen und Daten aller meiner Entwicklungsprojekte ablegt. Tatsächlich schreibt das Werkzeug während meiner Experimente keine einzige Datei außerhalb des Verzeichnisses »Ëœ/workspace« , wie mir ein mitlaufendes »strace -e file« anzeigt.

Nachdem ich den Workspace also einmal festgelegt habe, sehe ich die Oberfläche aus der Welcome-Perspektive (siehe Abbildung 1). Wenn Eclipse mehrere Unterfenster und Menüeinträge mit einem gemeinsamen inhaltlichen Bezug zusammenstellt, nennt es das eine Perspektive, beispielsweise fürs Programmieren inJava. Sie liefert mir leichten Zugang zum Hilfesystem, Tutorien und einigen Beispielen. Allerdings sind offen-bar nicht alle installiert, ich kann sie aber im zweiten Versuch von der Website der Eclipse Foundation herunterladen.

Abbildung 1: In der Welcome-Perspektive begrüßt Eclipse den Benutzer. Einsteiger finden so schnell und komfortabel Zugang zu Dokumentation und Beispielen.

Ich empfehle die wichtigsten Abschnitte der Hilfe-Dokumente zumindest zu überfliegen, denn dann klären sich viele Begriffe: Die Workbench umfasst die gesamte Oberfläche. Sie enthält mehrere kleinere Fenster, die ich in vielfältiger Weise nebeneinander oder übereinander, in Tabs gegliedert oder ikonifiziert anordnen darf. Diese Fenster heißen Parts und bestehen entweder aus einem Editor oder einer View. Mit letzterer kann ich hauptsächlich Strukturen in Listen- und Baumform durchsuchen.

Gewöhnungsbedürftig, aber zugleich auch faszinierend empfinde ich die Erfahrung, dass praktisch jeder Pixel, der sich in der Workbench befindet, eine Bedeutung hat: Da lassen sich Views verkleinern, andocken, Tabs aktivieren, deren Größe verändern, Bäume expandieren, Kontextmenüs ausfahren und vieles mehr. Mit den Bedienelementen komme ich recht einfach zurecht.

Umzudenken bedeutet für mich jedoch die Art, wie die Software Entwicklungsprojekte organisiert. In der Java-Perspektive finde ich links oben den Package Explorer, in dessen Kontextmenü ich allerlei neue Objekte anlegen kann, insbesondere so genannte Projekte. Die enthalten dann entweder Dateien oder Unterverzeichnisse, ähnlich wie ein Dateimanager. Und tatsächlich kann ich dort auch schlichte Textdateien erzeugen, bearbeiten und speichern.

Projekte managen

Neugierig schaue ich mir das Ergebnis außerhalb von Eclipse im Verzeichnis »workspace/Projektname« an und finde die Dateien dort in der gleichen Struktur. Insgeheim hatte ich komplexe XML-Dateien in schwer zu verstehenden Datenbank-Blobs erwartet. Das hat mich so gesehen positiv überrascht.

Noch mehr begeistert mich die Rückrichtung: Nachdem ich eine in Eclipse angelegte Datei außerhalb des Tools mit einem Emacs bearbeitet habe, weist mich die IDE auf die Änderung hin und fragt, ob sie diese in das Projekt übernehmen soll. Damit ist eine meiner größten Befürchtungen zerstreut, nämlich nicht mehr meine Unix-Lieblinge direkt auf den Code anwenden zu dürfen.

Bevor ich mich in die Java-Spezialitäten stürze, rät mir die Dokumentation, die Java-Umgebung zu prüfen. Im Dialog »Window | Preferences | Java | Installed JREs« lasse ich nach Java-Installationen unterhalb von »/usr« suchen und werde sowohl mit einer Open-JDK- [2] als auch mit einer Java-1.6-Installation direkt von Sun [3] fündig (siehe Abbildung 2). Beide sind Teil der Paketabhängigkeiten von Eclipse und der Kubuntu-Standardinstallation. Wer ernsthaft mit und für Java entwickeln will, benötigt zwangsläufig die vollständigen JDKs, denn die Runtime-Umgebungen enthalten schließlich nicht alle Quellen der Klassen.

Abbildung 2: Das Suchen, Finden und Einrichten von JDKs gelingt in Eclipse ohne nerviges Hantieren mit »CLASSPATH«-Umgebungsvariablen. Anwender dürfen sie sowohl global als auch projektbezogen auswählen.

Für jedes JDK geeignet

Als Nächstes finde ich heraus, dass es nicht nur einfache Projekte gibt, sondern sogar spezielle für Java. Lege ich ein solches an, stellt mir die verdunkelte Sonne eine Reihe von Fragen, darunter nach dem Projektnamen, der Version des JDK, das ich einzusetzen gedenke, sowie Bezüge zu anderen Projekten (siehe Abbildung 3). Hier erahne ich erstmals die Mächtigkeit des Framework gerade bei großen und sehr großen Projekten. So lassen sich etwa Abhängigkeiten, zusätzliche Bibliotheken und mehr definieren (siehe Abbildung 4).

Abbildung 3: Eclipse räumt Entwicklern viele Freiheiten ein. Neue Projekte dürfen sich auf bestehende beziehen, ein beliebiges JDK benutzen oder …

Abbildung 4: … Bibliotheken einbinden. Eclipse skaliert gerade bei großen Projekten mit verteilten Quelltexten und komplexen Buildprozessen gut.

Auch wenn es mir schwerfällt, nicht jede Option zu erkunden, bleiben bei mir diese Felder jedoch erst einmal leer. Ich lege stattdessen in meinem »src«-Folder eine neue Klasse an. Erneut erlebe ich einen übersichtlichen, aber umfassenden Wizard, der die wichtigsten Angaben zur Klasse abfragt (siehe Abbildung 5).

Abbildung 5: Ein Wizard fragt den Entwickler nach den wichtigsten Angaben für eine neue Klasse und spart damit Arbeit, etwa Konstruktoren zu schreiben.

Arbeit sparen, Wizard fragen

Darin unterscheidet sich ein IDE erheblich von den universellen Editoren wie Vi oder Emacs. Zwar beherrscht auch der Emacs ein Template-System und lassen sich im Vi mit etwas Mühe auch Shortcuts einrichten, um aber so viele Details zu bedenken, wäre sehr viel Konfigurationsarbeit nötig.

Da Java nun einmal eine ziemlich geschwätzig ist, kommen mir solche Hilfsmittel gerade recht: Im zugehörigen Editor zur Klasse steht bereits ein Rumpf des Codes. Zu Testzwecken erweitere ich meine Hello-Klasse etwas, füge eine Klassenvariable hinzu und entdecke im Menü »Source« einige nützliche Helfer, die ich mir immer gewünscht habe wie Code-Einrückung oder das automatische Generieren von Zugriffsmethoden (siehe Abbildung 6). Dabei geht Eclipse gar nicht einmal dogmatisch mit diesem Dingen um: Allein die Formatierungsdetails nehmen acht Reiter im Einstellungsdialog »Window | Preferences | Java | Code Style | Formatter« ein und lassen mir jede Freiheit zur Gestaltung meines Quelltextes.

Abbildung 6: Viele nützliche Helfer finden sich im Menü »Source«: Sie rücken ganze Dateien ein oder legen immer wiederkehrende Methoden nach Mustern an.

Die Sonne geht auf

Nach diesen Vorbereitungen komme ich endlich dazu, Quelltext einzugeben – und erleide einen Kulturschock: Das Coden in Eclipse unterscheidet sich vom Arbeiten mit mir vertrauten Editoren ähnlich fundamental wie Latex und Open Office das in der Sparte Textverarbeitung tun. Der Eclipse-Java-Editor registriert und analysiert jede einzelne Zeichen, das ich tippe. Syntaxfehler führen unmittelbar zu einem Warnicon am Anfang der Zeile, korrekte Schlüsselwörter färbt Eclipse ein.

Nach wenigen Zeichen eines Variablennamens schlägt mir die Software denkbare Ergänzungen vor. Bewege ich den Cursor auf einen Bezeichner, sehe ich alle seine Vorkommen im selben Fenster gelb hinterlegt: Hellgelb zeigt Eclipse Fundstellen an, bei denen ich die Variable auslese (R-Values), ein etwas dunklere Schattierung markiert Zuweisungen an sie (L-Values). Öffne ich eine geschweifte Klammer, so fügt das IDE nach dem Drücken von [Enter] sofort die passende schließende Klammer ein. Einrückungen passieren automatisch.

Nützlich ist auch ein Klick auf Methodennamen mit gehaltener [Ctrl]-Taste. In einem Kontextmenü darf ich nun wählen, ob ich ihre Deklaration oder ihre Implementation ansehen möchte. Am linken Rand des Editors fügt das IDE Symbole ein, die auf Probleme hinweisen (siehe Abbildung 7). Diese Fingerzeige gehen über rein syntaktische Probleme hinaus und warnen mich zum Beispiel vor Variablen, die ich niemals auslese: Das ist zwar der Form nach erlaubt, aber häufig ein Hinweis auf einen Tippfehler. Bewege ich die Maus über das Symbol, schlägt Eclipse gar typische Änderungen vor, um den Fall zu klären. Das ganze klappt natürlich nur, weil die Umgebung praktisch begleitend den Code übersetzt.

Abbildung 7: Die bearbeitete Methode vereinbart eine Variable »y«, nutzt sie aber nicht. Eclipse zeigt dies am linken Rand mit einem kleinen Icon. Klickt der Anwender auf darauf, schlägt das IDE drei Lösungen des Problems vor.

Gemeinsam mit Plugins

Das reine Editieren macht mir viel Spaß. Ich debugge viel mehr, während ich noch code und führe das Programm durch einen Klick auf ein Icon aus. Bislang musste ich jeweils den Editor verlassen, Makefiles anpassen, übersetzen, die Fehlerstellen suchen und anschließend beheben.

Um gemeinsam mit Kollegen an einem Repository zu arbeiten, kennt Eclipse von Haus aus offenbar nur CVS. Da ich aber gerne SVN oder Git verwende, schaue ich mich nach einem Plugin um. Sobald ich ein passendes Repository gefunden habe [4], trage ich es im Menü »Help | Install New Software …« ein, lade es herunter und lasse es installieren. Die Menge der angebotenen Plugins beeindruckt mich. Ein kurzer Test zeigt, dass selbst für Perl, Python und Co Editoren und Werkzeuge im Angebot sind.

Die Rechnung geht auf

Eclipse ist kein Tool, dass sich an einem Nachmittag erschließt. Froh darf sich derjenige schätzen, der von Kollegen oder in einer Schulung eine ausführliche Einweisung erhält. Ich habe mir den Einstieg in das IDE zwar mit RTFM erschlossen, doch viele der ausgeklügelten Details vermitteln Tutorials nur schwer. Kurze Skripte schreibe ich wohl weiterhin mit Emacs und Co. schneller. Bei meinem nächsten großen Programmierprojekt aber werde ich den ganzen Zeitraum über fahnenflüchtig.