Wenn Entwickler von Emacs und Vi zu Eclipse umsteigen

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.