Die Open Source-Entwicklungsumgebung Eclipse in Version 2.0

Die zweite Sonnenfinsterins

Stefan Matthias Aust, Michael Rusitska

Mit dem zweiten Release ist das Open Source-Projekt Eclipse eindeutig seinen Kinderschuhen entwachsen. Grund genug, dieses Projekt einmal näher anzuschauen und die neuen Möglichkeiten zur Java-Entwicklung zu betrachten. Der Name – Sonnenfinsternis – verleitet, eine Spitze gegen Sun zu unterstellen. Allerdings zielt das Eclipse-Projekt vielmehr darauf ab, eine integrierte Entwicklungsplattform zu schaffen, die mit Microsofts Visual Studio.NET konkurrieren kann.

Eclipse ist ein offenes Rahmenwerk zur Integration verschiedener Werkzeuge. Diese werden auf eine standardisierte Weise – über so genannte Plug-Ins – in die Hauptplattform eingefügt und können dann über die gemeinsame grafische Benutzeroberfläche, die Workbench, benutzt werden. Hauptbestandteil der Grundplattform ist eine vollständige Java-Entwicklungsumgebung (JDT, Java Development Tools). Sie wird inzwischen für die Weiterentwicklung von Eclipse genutzt, kann aber genauso gut für die Entwicklung eigenständiger Projekte oder neuer Plug-Ins eingesetzt werden.

Seit Juni 2002 ist nach intensiver Entwicklungsarbeit die Version 2.0 der Eclipse-Plattform verfügbar. Die Vorgängerversion diente bereits als Grundlage für IBMs WebSphere Studio Application Developer (WSAD) 4.x, dem Nachfolger von Visual Age for Java. Deshalb ist ein Einblick in die aktuelle Eclipse-Version auch ein Ausblick auf die kommenden kommerziellen WSAD-Versionen. Ähnlich wie Sun bei OpenOffice, nimmt IBM bei WSAD Eclipse als Grundlage und ergänzt das Produkt, um speziell Enterprise-Anforderungen abzudecken. Der Artikel stellt insbesondere die Java-IDE vor und geht auf die Unterschiede zur Version 1.0 ein.

Voraussetzungen

Eclipse ist unter [1] kostenlos verfügbar. Es ist in Java implementiert und benötigt ein JRE 1.3 oder höher. Aufgrund des verwendeten eigenen UI-Rahmenwerks SWT läuft Eclipse jedoch nicht auf jeder Java-Plattform. Unterstützt werden momentan:

  • Windows 98, ME, 2000 und XP
  • Linux/x86 mit Motif oder GTK+ 2.0
  • SPARC Solaris, HPUX oder AIX mit Motif
  • QNX (Photon)
  • MacOS X (Carbon)
  • Ab 256MB Hauptspeicher (je mehr desto besser) kann das Vergnügen beginnen.

Nach dem Starten von Eclipse präsentiert sich die Workbench dank SWT wie jede andere native Anwendung für das jeweiligen Betriebssystem. Da Eclipse mehr als eine Java-Entwicklungsumgebung ist, muss man zunächst die so genannte Java-Perspektive öffnen. Menü- und Werkzeugleiste geben erste Hinweise auf den Funktionsumfang. Zu beachten ist, dass sich je nach gewählter Perspektive der Funktionsumfang ändert. Die Perspektiven können vom Anwender individuell angepasst werden.

In der Mitte des Fensters, umgeben von sogenannten Views, befindet sich der Editorbereich. Je nach ausgewählter Ressource werden hier Strukturinformationen angezeigt und man kann den Quelltext bearbeiten. Die Anordnung der Views kann per Drag&Drop angepasst werden. Nicht mehr vorhanden ist die Möglichkeit aus Eclipse 1.0, diese auch in separaten floating windows von der Workbench zu trennen. Dafür gibt es jetzt so genannte Fast views, die automatisch zu einem Symbol verkleinert werden, sobald sie den Fokus verlieren.

Neue Perspektiven für die Java Entwicklung

Seit der Version 1.0 hat sich hier einiges getan. Nach wie vor müssen zur Java-Entwicklung ein oder mehrere Projekte angelegt werden. Dies geschieht über einen speziellen Wizard. Die Version 2.0 bietet dem Anwender die Auswahl aus drei unterschiedliche Perspektiven, mit diesen Projekten zu arbeiten.

Die Standard-Java-Perspektive ist ähnlich wie bei anderen Entwicklungswerkzeugen aufgebaut. Der Package explorer, ein Eclipse-View, bietet eine Java-spezifische Sicht auf Projekt-Ressourcen. Er zeigt beispielsweise Pakete, Klassen, deren Methoden und Felder.

Der Outline view zeigt die Struktur der im aktuellen Editor geöffneten Ressource an. Bei Java-Quelltext werden hier Klassen mit ihren inneren Klassen, Methoden usw. in einer übersichtlichen Baumstruktur angezeigt. Spezielle Symbole helfen, Sichtbarkeiten oder andere Eigenschaften, etwa ob eine Methode eine andere überschreibt, zu erkennen.

Der Hierarchy view (normalerweise verborgen hinter dem Package explorer) stellt die Vererbungsstruktur eines geöffneten Typs, also einer Klasse oder eines Interfaces, dar. Diese Ansicht hilft, auch in großen Projekten die Übersicht zu behalten. So kann man sich zu einer Klasse alle Unterklassen anzeigen lassen, zu einem Interface alle implementierenden Klassen, feststellen wo überall in der Klassenhierarchie eine bestimmte Methode implementiert wird, welche Interfaces eine Klasse implementiert und einiges mehr.

Unterhalb des Editorbereichs findet man drei weitere einander überlagernde Views: Der Console view zeigt die Standard- und Fehlerausgabe ausgeführter Java-Programme an. Der Search view stellt die Ergebnisse der verschiedenen und mächtigen Suchanfragen dar. Last but not least zeigt der Task view neben selbst definierbaren Aufgaben die aktuelle Menge an Fehlern und Problemen an, die bei der Arbeit aufgetreten sind. Filterfunktionen ermöglichen es auch hier, den Überblick zu behalten.

Die Java Type Hierarchy-Perspektive ist speziell für die Recherche innerhalb von Projekten geeignet. Sie bietet den direkten Zugriff auf den Hierarchy view. Umfangreicher ist die Java Browsing-Perspektive, die ähnlich aufgebaut ist, wie Visual Age for Java. Ihre Views filtern die Projekt-Ressourcen nach Packages, Types und Members. Diese Views befinden sich dabei über dem Editor. Die Sichtweise bietet damit das vertraute, Smalltalk-ähnliche Arbeiten auch mit Eclipse 2.0.

Unabhängig von der gewählten Perspektive stehen fast immer die selben Funktionen zur Verfügung. Sie können wie üblich über das Fenstermenü, die Symbolleiste oder aber, am bequemsten, über Kontextmenüs aufgerufen werden.

Abb. 2: Code-Recherche in der Java Browsing-Perspektive

An Funktionen bietet Eclipse das Gewohnte. Wizards helfen beim Anlegen neuer Projekte, Pakete, Klassen und Interfaces. Einzig Methoden muss man – im Gegensatz zu Visual Age for Java – selbst anlegen. Dafür kann man diese bequem per Drag&Drop über Outline view oder Package explorer kopieren oder verschieben. Auch Klassen können so zwischen Paketen verschoben werden, alle Referenzen werden dabei selbstverständlich angepasst.

Erwähnenswert ist die Möglichkeit, eine so genannte Scrapbook-Seite anzulegen. Hier können Code-Schnipsel eingegeben und sofort, ohne explizite Kompilation, ausprobiert werden.

Über den Outline oder Members view kann man automatisch getter– und setter-Methoden generieren lassen. Ebenfalls kann Eclipse automatisch Methodensignaturen aus Oberklassen kopieren und so etwa beim Ableiten von abstrakten Klassen zu implementierende Methoden generieren lassen. Für Eclipse 2.0 wurden alle Kontextmenüs überarbeitet und besser strukturiert.

Edit as Edit can

Herzstück des JDT ist natürlich der Java-Editor. In Zusammenarbeit mit den oben beschriebenen Views stellt man fest, dass das Eclipse-Team hier mit viel Liebe zum Detail vorgegangen ist. Fast in jeder Situation bietet der Editor durch Drücken von Strg+Leertaste eine Hilfestellung. Man kann package oder import-Deklarationen komplettieren. Innerhalb von Klassendefinition kann man sich Methodensignaturen für aus Oberklassen vorhandenen Methoden einfügen lassen. Zudem kann man mit Hilfe des Template-Generators, der ebenfalls über Strg+Leertaste aktiviert wird, generische Methoden-Templates einfügen lassen. So reicht etwa ein main, um die übliche Startmethode einer Java-Anwendung in den Quelltext einzufügen.

Auch innerhalb von Methoden können Templates bei der Eingabe helfen. Ein for reicht, um etwa über ein Array oder eine Collection zu iterieren. Die Namen der Laufvariable oder des Arrays können dabei eingestellt werden, müssen jedoch nur einmal angegeben werden, da innerhalb des Templates automatisch alle Vorkommen passend benannt werden. Eclipse versucht dabei, gute Variablennamen zu finden. Steht vor dem for eine Array-Definition, so wird dieser Name benutzt. Außerdem können all Templates angepasst oder nach eigenen Wünschen erweitert werden.

Code completion für Methoden und Felder ist eigentlich heute eine Standard-Anforderung bei Java-IDEs, deshalb bietet auch Eclipse diese Funktion. Nach kurzer Wartezeit oder durch Drücken von Strg+Leertaste öffnet sich ein Assistent, der alle an der jeweiligen Stelle syntaktisch möglichen Alternativen präsentiert. Kurze Zeit später wird auch der JavaDoc-Text zum ausgewählten Kandidaten angezeigt. Entscheidet man sich für eine bestimmte Methode, bietet Eclipse schließlich noch eine Ausfüllhilfe für die Parameter (mit den korrekten Parameternamen, sofern das System Zugriff auf den Quelltext dieser Methode hat). Seit Version 2.0 bietet Eclipse außerdem genau wie bei den Templates die Möglichkeit an, mit TAB zwischen den auszufüllenden Parametern zu wechseln und so einfacher nur die jeweils notwendigen Informationen eintragen zu müssen.

Abb. 3: Beispiel für die Code Completion

Besonders praktisch ist die Code completion auch bei inneren Klassen. Um etwa einen ActionListener zu implementieren, reicht es, nach dem Text new ActionListener( die Completion auszulösen, und Eclipse fügt automatisch die notwendige Methode hinzu. Gibt es mehr als eine Methode, öffnet sich ein Auswahldialog.

Dies ist jedoch nicht die einzige Möglichkeit, sich bei der Eingabe helfen zu lassen. Eclipse 2.0 prüft sofort bei der Eingabe den Code und markiert fehlerhafte Stellen ähnliche wie eine Textverarbeitung mit einer roten Schlangenlinie. Das ist an sich noch nichts besonderes. Fast immer bietet Eclipse jedoch auch eine Auswahl von Vorschlägen, wie dieser Fehler korrigiert werden kann, den sogenannten QuickFix. Über Strg+1 kann ein Popup-Menü geöffnet werden, welches anbietet, falsch geschrieben Methoden zu korrigieren, neue Methoden zu implementieren, Imports oder Casts hinzuzufügen und einiges mehr. Benutzen Sie das Feature nicht zu oft, es macht abhängig …

Abb. 4: QuickFix für eine fehlerhafte Codezeile

Vier Symbole der Workbench-Symbolleiste gehören zu dem Editor. Mit dem ersten Show Source of Selected Element only kann man die Ansicht auf das im Outline view ausgewählten Element beschränken und so eine Darstellung wie in VisualAge for Java einschalten. Das zweite Symbol schaltet die Hoverhelp-Fenster im Editor ein oder aus, die automatisch den JavaDoc-Kommentar des Java-Elements anzeigen, über dem sich der Mauszeiger befindet. Mit den anderen beiden Symbolen kann man zum nächsten bzw. vorherigen Fehler im Editor springen. Alternativ geht das auch mit Stg+. oder Strg+.

Wird im Editor gespeichert, übersetzt Eclipse normalerweise sofort alle betroffenen Dateien neu. Fehler bei der Übersetzung werden durch kleine Symbole am Rand des Editors markiert. Weg mag, kann auch die Anzeige von Zeilennummern hier aktivieren. Am rechten Rand neben dem Rollbalken, auch eine Neuerung der Version 2.0, zeigen kleine Kästchen die Anzahl und Position der Fehler relativ zur Gesamtdateigröße an. Per Mausklick kann man so schnell zu einem Fehler springen.

Fehlerkontrolle

Eine Applikation kann alternativ im Debug-Modus oder in der Debug-Perspektive gestartet werden, die wiederum spezielle Views bietet.

Der Debug view zeigt Threads und Stacktrace der untersuchten Programme. Hier kann man das Programm anhalten, schrittweise durchlaufen, fortsetzen oder abbrechen. Man kann mehr als ein Programm gleichzeitig debuggen. Er unterstützt außerdem das Remote-Debugging.

Daneben findet man vier sich überlagernde Views. Der Variables view zeigt die in der gerade selektierten Methode sichtbaren Variablen mit ihren Werten.

Im Breakpoints view erhält man eine Übersicht über alle definierten Breakpoints und kann deren Eigenschaften bearbeiten. Seit Eclipse 2.0 gibt es auch bedingte Breakpoints, wo über einen Java-Ausdruck angegeben werden kann, wann der Breakpoint stoppen soll. Auch das Stoppen erst nach dem Xten Durchlauf ist möglich. Schließlich hat man die Wahl, ob nur der aktueller Thread oder die gesamte VM angehalten werden soll. Neben normalen Breakpoints im Quelltext sind auch nach wie vor Breakpoints auf Exceptions möglich.

Über den Expressions view kann man bestimmte Ausdrücke beobachten, die man über Inspect im Variables oder Display view auswählt. Der Display view wiederum bietet eine Art Mini-Scrapbook, das allerdings direkten Zugriff auf alle Variablen des Variables view hat. Hier kann man beliebige Java-Ausdrücke eingeben und sofort auswerten lassen.

Setzt man JDK 1.4.1 ein, unterstützt der Debugger das Hot code replacement dieser JVM. Hierbei können einzelne neu übersetzte Klassen im laufenden Programm ausgetauscht werden. Man muss also nicht nach Änderungen während des Debuggen neu starten, sondern kann die Programmausführung im Debugger einfach fortsetzen. Dies ist nichts Neues für Smalltalker oder User von Visual Age for Java, aber doch eine Neuheit für dateibasierte Java-Entwicklungsumgebungen.

Team-Arbeit

Gerade wenn mehr als eine Person an einem Projekt arbeitet, werden Werkzeuge zur Unterstützung der Entwicklungsarbeit benötigt. Für Eclipse 2.0 wurde diese Unterstützung komplett neu implementiert, so wird standardmäßig nach wie vor das CVS (Concurrent Versioning System, [4]) unterstützt. Die Unterstützung für andere Versionsverwaltungssysteme (etwa ClearCase oder SourceSafe) kann als Plug-In nachgerüstet werden.

Versuchte Eclipse 1.0 noch die Details der zentralen Quelltextverwaltung vor dem Anwender zu verbergen, werden jetzt alle Möglichkeiten von CVS unterstützt. Ein Entwickler, der CVS bereits eingesetzt hat, wird auch mit Eclipse keine Probleme haben. Dabei sind die typischen Arbeitsabläufe komplett in die Entwicklungsumgebung integriert.

Endlich kann Quelltext auch als ASCII-Text eingecheckt werden und werden CVS-Schlüsselworte unterstützt. Abhängig von der Dateiendung kann bestimmt werden, ob Ressourcen im Text- oder Binärformat gespeichert werden sollen.

Nicht immer will man jede Datei im eigenen Projektordner ins Repository stellen. Über die .cvsignore-Datei kann man konfigurieren, welche Verzeichnisse oder Dateien ignoriert werden sollen. Diese Datei kann jetzt über ein Menü im Navigator und Synchronize view automatisch gepflegt werden.

Auch für das Hinzufügen neuer Ressourcen, das Nachladen von Ressourcen und der Abgleich des eigenen Quelltextes mit dem Repository gibt es Menüpunkte unterhalb des Team-Menüs.

Besonders die Möglichkeiten des Abgleichs wurden verbessert. Neben einem einfachen Textvergleich wird auch die Struktur bestimmter Ressourcen, etwa von Java-Quelltext, .jar-Dateien oder ganze Projektbäume verglichen, sodass man auch hier Hinzufügungen, Änderungen und Löschungen erkennen kann. Ein spezieller Merge editor hilft, Konflikte zwischen verschiedenen Quelltextversionen zu erkennen und aufzulösen. Synchronize view und Merge editor heben dabei die Unterschiede hervor und teilen durch Linien den Quelltext in gemeinsame und unterschiedliche Bereiche ein. Nützlich ist auch die Anzeige der Änderungen rechts neben dem Rollbalken, in der kleine Kästchen die Anzahl und Position der Änderungen relativ zur Gesamtdateigröße anzeigen und über die man durch Anklicken schnell zu einer anderen Position springen kann.

Abb. 5: Vergleich zweier Versionen eines Projekts

Um jederzeit einen Überblick über den Änderungsstand des eigenen Projekts zu haben, kann man über die Preferences so genannte Label decorators dazu schalten, die im Package explorer und Navigator view in Form spezieller Symbole anzeigen, ob eine Datei unter Versionskontrolle steht, neu hinzugefügt oder verändert wurde, und welche Version gerade geladen ist.

CVS-Client und Server können Daten komprimiert austauschen, was natürlich gerade bei Quelltext Übertragungszeit einsparen hilft. Dies bewirkt eine deutliche Beschleunigung beim Laden oder Vergleichen von Quelltext.

Last but not least bietet Eclipse 2.0 Unterstützung für das bequeme tagging, das Zuweisen einer Versionsmarke an Ressourcen, so genannten branches und eine CVS-Console für die Ausgabe von Fehlermeldungen.

Tatsächlich bietet Eclipse die wichtigsten Funktionen eines komfortablen CVS-Verwaltungssystems und selbst wer keine Java-Entwicklung betreiben will, kann Eclipse immer noch als grafisches Frontend für CVS benutzen. Dank des Plug-In-Konzepts könnte man den normalen Download-Umfang für diese Spezialaufgabe deutlich reduzieren und so ein spezielles Entwicklerwerkzeug schaffen. Dieses wurde bereits in der deutschsprachigen Java-Newsgroup [5] diskutiert und exemplarisch realisiert.

Die Workbench – Arbeitsplatz für den Entwickler

Eine IDE ist wie ein paar gute Schuhe. Hat man die Schuhe erst eingelaufen und fühlt sich wohl, will man sie nicht mehr wechseln. Sollte man also auf Eclipse 2.0 umsteigen? Wer bereits die erste Version benutzt und gut gefunden hat, wird nicht zögern. Es gibt nur Verbesserungen.

Wer bislang Visual Age for Java benutzt, wird über lang oder kurz zu WSAD oder einer anderen IDE wechseln müssen, da IBM die Weiterentwicklung von Visual Age eingestellt hat. WSAD ist der offizielle Nachfolger, bietet momentan aber noch keinen GUI-Builder. Hot code replacement ist ebenfalls noch nicht in der 4.x-Version vorhanden. Hier bietet Eclipse 2.0 mehr, allerdings aufgrund der Beschränkungen von Suns JVM noch nicht so viel, wie VisualAge dank seines Smalltalk-Erbes bot. Hier besteht momentan die Hoffnung, das IBMs eigene Version des Java SDKs in der Version 1.4 eine VM bieten wird, die auch mit Änderungen der Klassenstruktur während des Debuggens klar kommt.

Wer mit dem speziellen Repository von Visual Age oder der Beschränkung auf JDK 1.1 oder 1.2 nicht mehr leben kann, sollte ebenfalls über einen Umstieg auf Eclipse nachdenken. Eclipse bietet freie Wahl bei der Versionsverwaltung und der JDK-Version. Hot code replacement setzt allerdings die Version 1.4 voraus und wer unter JDK 1.1 entwickeln muss, hat keinen Debugger-Support – ein inzwischen übliches Problem, da alle modernen IDEs die erst ab JDK 1.2 verfügbare Java-Debugger-Schnittstelle benutzen.

WSAD bietet gegenüber Eclipse Unterstützung für das Bearbeiten von JSPs-Dateien (inklusive code completion), XML-Dateien und HTML-Dateien sowie eine Reihe von Wizards für den Umgang mit dem Websphere Application Server, Datenbanken und Webservices. Auch ein eigener Profiler liegt dem Produkt bei. Wem es reicht, ähnliches über Plug-Ins selbst nachzurüsten oder auf derartige Komfort-Funktionen verzichten kann, für den ist Eclipse eine gute Alternative.

Wer bereits das freie Netbeans einsetzt, wird beim Umstieg auf Eclipse vielleicht den GUI-Builder vermissen. Ansonsten sind die Möglichkeiten vergleichbar, ja scheinen die Projektteams bestrebt, die Features des Konkurrenzproduktes in der jeweiligen nächsten Version ebenfalls zu bieten. Dem Anwender kann das nur recht sein. Netbeans läuft dank Swing-GUI unproblematischer auf mehr Plattformen, benötigt jedoch etwas leistungsstärkere Rechner und sieht – unserer Meinung nach – nicht ganz so schick und aufgeräumt aus, wie Eclipse. Da beide Produkte jedoch frei sind, sollte sich hier jeder selbst eine Meinung pictureen.

Die Workbench – Arbeitsplatz für den Entwickler

Viele Detailverbesserungen der Version 2.0 konnten aus Platzgründen nicht erwähnt werden. Während die erste Version die typischen Ecken und Kanten eines Erstlingswerks hatte, kann man Eclipse 2.0 als solide und stabile Entwicklungsplattform bezeichnen, bei der es Spaß macht, sie zu benutzen. Sie ist mit kommerziellen Entwicklungsumgebung vergleichbar, besticht aber natürlich, ähnlich wie Suns Netbeans Projekt, durch ihr Preis/Leistungsverhältnis. Einzig ein GUI-Builder und bessere Packaging-Mechanismen vermissen wir.

Dipl.-Inform. Stefan Matthias Aust und Michael Rusitska sind Gründerder 3plus4software GbR, Kiel, die sich auf die Unterstützung und Durchführung objektorientierter Softwareobjekte in Java und Smalltalk spezialisiert hat.

Geschrieben von
Stefan Matthias Aust, Michael Rusitska
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.