In jeden der neun Milestones, die Eclipse 3 innerhalb eines Jahres durchlief, packte die Entwicklermannschaft neue interessante Funktionen. Jeder Milestone würde locker einen ganzen Artikel voller Aufzählungen füllen. An dieser Stelle wollen wir uns aber auf den Eclipse Editor als Haupteingabemedium konzentrieren und einen Blick auf die neuen Features des Editor werfen.

Licht ins Dunkel der Methoden

Wem die reine Visualisierung von Java-Schlüsselwörtern (und das sind ja nicht so viele) in Eclipse vollkommen ausreicht, der kann auf Semantic und Syntax Highlighting sowie Occurrence Marking sicher gut verzichten. Für alle, die leidenschaftlich gerne lange Klassen und Methoden schreiben, könnten die nachfolgenden Features aber Klarheit in die Codestruktur bringen. Um davon Gebrauch zu machen, aktiviert man folgende Funktionen in den Eclipse Preferences (Window | Preferences). Für einen Teil von ihnen ist ein komplettes Recompile der Projekte notwendig.
Improved Syntax Highlighting: Java | Editor | Syntax | Enable advanced highlighting: dient der Markierung einer Reihe von Java-Ausdrücken (Variablen-)Deklarationen, Aufruf vererbter Methoden, Konstanten, statischer Felder ...

Unused Code: Java | Compiler | Unused Code: Obwohl nicht unbedingt problematisch, so doch zumeist überflüssig und verwirrend ist nicht verwendeter Code, besonders wenn er aus fremder Feder stammt. Da Eclipse einen eigenen Compiler nutzt, können diese Stellen von ihm explizit aufgespürt werden. Über entsprechende Combo-Boxen können die Prüfungen auf nicht verwendete lokale Variablen und Parameter, ungenutzte private Felder, unnötig geworfene Exception-Typen und neuerdings auch unnötige cast- oder instanceof-Aufrufe vom Default-Wert Ignore auf Warning oder Error geschaltet werden, um diese bei der Editierung kenntlich zu machen.

Coding sStyle: Java | Compiler | Style: Ähnlich wie auch bei unbenutztem Source hängt es von den jeweiligen Projektkonventionen ab, wie streng das Thema Stilrichtlinien gehandhabt wird. Eclipse meint damit nicht, ob Sie Ihren Sourcecode sauber eingerückt und umbrochen haben (dazu kommen wir noch), sondern kleinere Vergehen wie leere, undokumentierte Catch-Blöcke, möglicherweise versehentliche Zuweisungen in Boolschen Bedingungen (if (a=b){}) oder einfach leere Statements. Auch diese Prüfungen können Sie in einer entsprechenden Combobox von Ignore auf Warning oder Error setzen, falls derartige Unsauberkeiten für Sie nicht in Frage kommen dürfen.

Mark Occurrences: Java | Editor | Mark occurrences: Kennen Sie das Gefühl, dass Sie in einem langen Methodenblock die Übersicht verlieren, wo überall der ein Exception-Typ geworfen, die eine Methode verwendet oder die eine Variable benutzt wird? Wenn dem so ist, aktivieren Sie die Mark occurrences-Funktion und nach einem Klick auf eines der von Ihnen ausgewählten Elemente erscheinen die anderen gleichzeitig markiert im Editor.
Abpictureung 1 zeigt eine Beispielmethode, bei der die oben genannten Visualisierungseinstellungen aktiviert wurden. Eine überflüssige IOException, ein undokumentierter else-Zweig und ein leeres Statement sind mit Warnungen versehen, das Vorkommen des originalContent-Parameters markiert und statische Source-Elemente sind kursiv gedruckt.

Gefaltet und verpackt

Mit Microsofts Visual Studio .NET kam es u.a. groß in Mode: das Falten der Sourcecode. Alles, was gerade nicht benötigt wird, wird weggeklappt (Methoden, Kommentare, Import-Statements). Eclipse 3.0 hat nach der Sun-Vorlage in Netbeans 3.6 nun auch das Source Folding erlernt. Wer nur einen 15- oder 17-Bildschirm sein Eigen nennt, verschafft sich dankbar Überblick bei großen Klassen. In den Eclipse Preferences lassen sich die Einstellungen für das Folding ändern. Gefaltete Elemente kann man über kleine Dreieckssymbole am linken Editor-Fensterrand manuell auseinander und zusammenklappen. Zusätzlich sehr angenehm: Mit der Maus über den zusammengefalteten Bereich gefahren, erscheint dieser in einem kleinen Tooltip-Text eingeblendet.

Default Folding Settings: Java | Editor | Folding: Hier lassen sich Standardvorgaben einrichten, welche Teile des Source zusammengefaltet dargestellt werden sollen, wenn im Editor eine Klasse geöffnet wird.

Kleine Unterschiede gesucht

Wenn Sie ein alter Eclipse-Hase sind, kennen Sie längst die History-Fähigkeiten von Eclipse, die zu einer Klasse oder Methode die letzten gespeicherten Stände wieder abrufbar macht. Egal, ob Sie über eine darunter liegende Versionskontrolle verfügen oder nicht. Eclipse bietet im Menüpunkt Compare With | Element from local history im Kontextmenü des jeweiligen Elementes einen Vergleichsdialog an, in dem Sie nach den Vorher-Nachher-Unterschieden suchen können.
Meist möchte man aber nur wissen, welche Stellen im Source man seit dem Speichern in den letzten paar Minuten modifiziert hat. Diese Funktion nennt Eclipse Quick diff. Quick diff ist standardmäßig aktiviert und seine Einstellungen können über die rechte Maustaste links neben dem Editor im schraffierten Bereich verändert werden. Grundsätzlich markiert Eclipse jede hinzugefügte Zeile durch einen kleinen lilafarbenen Balken. Sollten Sie in den Editor-Einstellungen die Anzeige der Zeilennummern aktiviert haben, sind genau diese jetzt farblich unterlegt (Abb. 2). Der Quick diff zeigt ergänzte und gelöschte Zeilen und kann selbstverständlich auf Wunsch auch deaktiviert werden.

Das Leid mit der Dokumentation

Sollten Sie als Architekt oder Projektleiter ein Team von Entwicklern unter sich haben, kennen Sie das Problem sicher zur Genüge. Ist das Projekt beendet, die Software fertig, sieht's mit Dokumentation und sogar mit dem einfachen Javadoc nicht selten relativ mau aus. Entweder fehlt der Kommentar ganz, was vielleicht erst umständlich mit Tools zum Build-Zeitpunkt zum Fehler führt. Die Javadoc-Tags sind falsch, weil durch Copy/Paste oder Refactoring die Signatur nicht mehr zum Kommentar passt oder der werte Kollege den wenigen Zeilen gar grausamstes Englisch zugemutet hat. Für all das bietet Eclipse 3 eine Lösung, von Kleinigkeiten wie dem Umbruch von Beispielen in Kommentare nach empfohlenen 70 Zeichen (man nehme die Sun Code Conventions, Abschnitt 4.1, zur Hand und prüfe) mal ganz zu schweigen.

Dass Eclipse neuen Javadoc für bestehende Signaturen sehr schnell mit den richtigen Tags füllt, war bereits in Version 2.1 vorgesehen. Eclipse 3 bringt in den Eclipse Preferences im Unterpunkt Java | Compiler | Javadoc erweiterte Fähigkeiten mit. Neben dem grundsätzlichen Aktivieren und Deaktivieren des Interesses an Javadoc kann man hier den Schweregrad falscher Kommentare einstellen. Gleichzeitig berücksichtigt Eclipse auch notwendige Tag-Änderungen, die durch Eclipse-Refactoring-Maßnahmen verursacht werden. Bei Rename, Move und dem Wechsel der Methodensignatur korrigiert Eclipse die @see- @link- @param- und @throws- Tags automatisch.
Wer nun trotzdem mühselig einen falschen Kommentar zustande gebracht hat, dem hilft Eclipse mittels Quick-fixes-Erweiterungen. Ist die Option für fehlende Javadoc-Tags mindestens auf Warning geschaltet, so bietet Eclipse an, fehlende Tags auch auf Wunsch zu ergänzen (Abb. 3). Wer sich nun auch noch eine inhaltliche Prüfung seines Kommentars wünscht, dem kann hier über eine Einstellung in den Preferences geholfen werden.

Dictionary: Java | Editor | Spelling | Spell-check comments: Eclipse bringt mit Version 3.0 eine Wörterbuchprüfung für Ihre Kommentare mit. So Sie denn viel und umfangreich in englischer Sprache im Javadoc beschreiben, kann sich dies als sehr hilfreich erweisen. Auf Wunsch berücksichtigt Eclipse dabei zusätzliche Wörterbücher oder auch das Auslassen spezieller Begriffe wie gemischte Zahl-Wort-Kombinationen.

Templates und Proposals

Sollten Sie sich zur Erstellung einer While-Schleife eines Content-Assistenten bedienen oder ein Template z.B. für ein Logging-Statement oder die Generierung eines Singleton selbst schon einmal geschrieben haben, kennen Sie bereits die reichhaltigen Eclipse-Möglichkeiten zur Erstellung von Templates. Wer sich z.B. daran störte, dass beim automatischen Generieren von Accessor-Methoden kein this vor der Variable erscheint, dem hilft mittlerweile die Einstellung Java | Code Generation | Code and Comments | Getter und Setter body in den Preferences.
Zugegebenermaßen ist nun das Anklicken aller Felder, die eine solche Methode bekommen sollen, zuweilen zeitaufwendig, weshalb Eclipse hier einen kleinen Trick bereithält. Die Erzeugung von Gettern, Settern, Default-Konstruktoren und Methoden-Stubs unterstützt der Editor, indem man für einen Getter z.B. lediglich das Wort get eintippt und dann mit STRG + Leertaste den Assistenten aufruft, der einem eine Menge von Generierungsmöglichkeiten (Proposals) vorschlägt.

Je nach syntaktischem Zusammenhang haben die Template-Generatoren zudem dazugelernt, aus der Menge der möglichen Variablen und Inhalte jene herauszufiltern, die im Kontext des zu erstellenden Statements Sinn machen. Bliebe noch zu ergänzen, dass Eclipse nun auch die Erstellung von Konstruktoren mit vielen Parametern (was schon allein ob der Zuweisungs-Statements keine Freude beim Programmieren ist) mit dem neuen Java-Kommando Source | Generate Constructor using Fields über das Kontextmenü für den Entwickler bereithält.

Kleine Import-/Export-Kunde

Eclipse hat die Zeiten, in denen man noch mit wilden .*-Import-Statements ein ganzes Package in die Klasse importierte (man kann sich schon auf statische Imports von J2SE 5.0 freuen), für Entwickler schon lange ad acta gelegt. Ein schnelles Organize Imports über das Kontextmenü aufgerufen, beschert eine sauberen Import-Statement-Block am Klassenanfang. Bliebe nur die Tatsache, dass ja schon der Aufruf dieser Funktion irgendwie überflüssig ist, besonders wenn man nur ein paar Zeilen oder eine Methode per Copy/Paste von einer Klasse in eine andere verschiebt. Hier kontert Eclipse inzwischen mit der Fähigkeit, diese Imports tatsächlich automatisch zu ergänzen. Nur in Ausnahmefällen, z.B. bei mehrdeutigen Klassennamen, ist der Editor weiterhin auf die Mithilfe des Entwicklers angewiesen.

Interessanterweise unterstützt Eclipse sogar bei Build-Path-Problemen, z.B. wenn die in der Klasse referenzierte Fremdklasse sich zwar in Eclipse befindet, der Projektklassenpfad aber nicht entsprechend ergänzt wurde. Dann helfen die kleinen Quickfix-Helfer weiter, ohne groß den Build Path des Projektes anpassen zu müssen.

Code Conventions

Manch einer hat sich durchaus zu Recht über den CodeFormatter von Eclipse 2.1 beklagt. Ein paar dürftige Checkboxen und ein Formatter, der sich für das Einrücken und Umbrechen von Kommentaren im Source nicht gerade stark machte, riefen bei vielen Benutzern die Suche nach adäquatem Ersatz in Form von Plug-ins hervor. Die aktuelle Version der IDE nimmt es dafür mit den Konventionen schon sehr genau. In den Java Preferences findet sich nun im Unterast Java | Code Style | Code Formatter eine Formatierungsfunktion, die sowohl die alte Eclipse 2.1-Variante, aber auch die anerkannten Sun Code Conventions beherrscht. Selbstverständlich darf hier, wer möchte, seinen eigenen Stil definieren. Wie sieht die Einrückung aus, wo müssen die Klammern hin, wie viele Leerzeichen sind wo erlaubt, wie viele Leerzeilen dürfen zwischen welchen Klassenelementen liegen, wo dürfen Sourcecode-Zeilen und wo Kommentare umgebrochen werden?
Wer ganz unbedacht in Eclipse 3 die Formatfunktion ausführt, könnte denn aber auch die eine oder andere Überraschung erleben. Schnell ist der mit handverlesenen Leerzeichen eingerückte Kommentar zu einem wilden Sammelsurium aus HTML-Tags und Zeilenumbrüchen degradiert. Konventionskonform, aber nicht unbedingt immer schön.

Noch mehr Erweiterungen?

Martin Fowler sei Dank gibt es mit der neuen Eclipse-Version auch zusätzliche Refactorings, z.B. Einführen von Fabrikmethoden zum Erzeugen von Objektinstanzen oder der erweiterte Support für Exceptions beim Ändern von Signaturen. Besonders die immer besser werdenden Refactoring-Eigenschaften und sehr gute View-Elemente zum Anzeigen von Source-Strukturen, Vererbungshierarchien oder Klassenelementen machen es dem Entwickler wieder ein Stück leichter, in eigenem und fremden Sourcecode Fuß zu fassen. Die neuen Funktionen von Eclipse setzen auf das bereits sehr gute Handling von großem Source in Eclipse 2.1 wieder eins drauf.

An dieser Stelle findet dieser Artikel aufgrund des Umfanges des Themas sein vorläufiges Ende. Er stellte in Auszügen und Beispielen Themengebiete und Grundlagen der Eclipse IDE vor, wie sie im Einführungskapitel des neuen Eclipse 3-Buches des Software & Support Verlages behandelt werden. Für weitergehende Informationen und einen tieferen Einstieg in die neue Eclipse IDE und ihre Funktionen rund um den Editor und andere Komponenten sei auf die verfügbare Literatur und das Eclipse Special des Java Magazins verwiesen.