Während der Fahrt zur Arbeit überlege ich, wie es mit Eclipse wohl weitergeht. Mit seinen mächtigen Refactoring-Funktionen und den vielen Quickfixes hat Eclipse meinen Alltag als Java-Entwickler revolutioniert. Damals, zu den Anfangszeiten von Java, glich Softwareentwicklung ohne Aufruf- und Klassenhierarchie oder den Navigations- und Suchmöglichkeiten, die Eclipse heute bietet, einem Blindflug.
Eclipse – die Java IDE
Eclipse ist für mich vor allem die Java-Entwicklungsumgebung, die ich fast täglich nutze. Auch wenn ich rundum zufrieden bin, gibt es viele Ideen, die das Programmieren mit Eclipse noch effizienter machen könnten. Die aus meiner Sicht vielversprechendsten Ideen stelle ich im Folgenden vor.
Der Editor im Editor
Mit dem Lesen von Quelltext verbringe ich mehr Zeit als mit dem Schreiben. Dass bereits beim Darüberfahren mit der Maus der entsprechende Javadoc-Kommentar des implementierten Interfaces, der überschriebenen Methode oder der Deklaration angezeigt wird, erspart mir das Öffnen der entsprechenden Datei oder das Springen dorthin. Direkt im Quelltext ist aber Javadoc durch die unproportionale Schrift und die vielen Auszeichnungs-Tags schlecht zu lesen. Statt die Javadoc View zu bemühen, würde ich mir "gerendertes" Javadoc direkt im Java-Editor wünschen (Abb. 1). Und warum sollte es nicht gleich möglich sein, den Kommentar in dieser Ansicht zu editieren? Ein kleiner WYSIWYG-Editor im Editor sozusagen.
Eine solche abstraktere Darstellung des Quelltexts könnte auch Javas Geschwätzigkeit bei Gettern und Settern eindämmen: Eine einzige Instanzvariable bedarf zweier zusätzlicher, zumeist einzeiliger Methoden. Der dazugehörige Javadoc-Kommentar ist keinmal, einmal oder mehrfach an den drei Stellen zu finden. Die abstrakte Darstellung würde dagegen alle drei Bereiche zu einem untrennbaren Absatz verschmelzen, der den Code der Getter- und Setter-Methoden direkt unterhalb des Kommentars und der Variablendeklaration anzeigt. Falls die Variable ausschließlich gesetzt bzw. zurückgegeben wird, könnte statt des Codes ein einzelnes Symbol das Vorhandensein visualisieren. Ebenso könnten in der Outline View drei Einträge durch einen Eintrag ersetzt werden, indem z.B. das Icon der Instanzvariable mit einem Pfeilchen nach rechts (Setter) oder nach links (Getter) dekoriert würde. Auch die Java-Suche würde nicht schon bei Gettern und Settern, sondern erst bei deren Aufrufen Halt machen.
Vielleicht wäre diese Art von Darstellung auch das fehlende Bindeglied zwischen Quelltext und UML. Das am MIT entwickelte Eclipse-Plug-in Relo demonstriert eindrucksvoll die Verschmelzung von Klassendiagramm und Quelltext (Abb. 2). Dafür verzichtet Relo aber auf die gewohnten Editoren und zeigt den Quelltext direkt innerhalb einer einzigen und durch Navigation größer werdenden Grafik an. Eine gesamte, klassenübergreifende Änderung mitsamt ihren Verflechtungen mit dem restlichen Code in einer Grafik zusammengefasst kann Dokumentation und Diskussionsgrundlage zugleich sein. Dazu müsste Relo lediglich einen von Mylyn erfassten Kontext oder den Inhalt eines Patchs importieren und darstellen können.
Auch anderen Editoren wie dem Ant-Editor würde eine teilweise grafische Darstellung gut zu Gesicht stehen. Statt XML-Elemente und Attribute zu editieren, wären Ant Tasks als Blöcke zusammenzuklicken – insbesondere für Gelegenheitsnutzer sicherlich eine Erleichterung.
Compare macht den Unterschied
Eine Funktion, mit der man auch bei Nichtentwicklern Eindruck schinden kann, ist der eingebaute Compare-Editor. Zwei Dateien oder Java-Elemente wie Methoden können verglichen und gegebenenfalls zusammengeführt werden. Sogar auf die automatisch protokollierte Dateihistorie kann diese Funktion angewandt werden. Zwar können nichtdruckbare Zeichen ignoriert werden, dennoch könnte man sich wünschen, dass vor dem Vergleich der Formatierer und die Clean-up-Funktionen auf beide zu vergleichenden Quelltexte angewandt würden, um nur echte Unterschiede anzuzeigen.Die Refactoring-Vorschau ist schon klasse. Noch bevor die Änderung tatsächlich durchgeführt wird, ist zu sehen, welche Bereiche wie geändert werden. Gegebenenfalls lässt sich dann ein Refactoring auch nur partiell anwenden. So eine Was-wäre-wenn-Vorschau wäre auch prima beim Auflösen von zirkulären Abhängigkeiten, die z.B. von JDepend zwischen Paketen oder FindBugs auf Klassenebene gefunden werden. Neben textuellen Veränderungen könnten Metriken die Vorschau bereichern, um auf Qualitätsverbesserungen oder -verschlechterungen hinzuweisen. Einen schnellen Rechner vorausgesetzt, könnte gar eine Überprüfung mittels JUnit-Tests bereits in diesem Szenario stattfinden.
Auch bei den Compiler-Warnungen würde ich mir wünschen, die aktuelle Liste mit einem frühen Stand vergleichen zu können, um herauszufinden, welche Warnungen beseitigt wurden und welche neu hinzukamen. Gerade beim Arbeiten in großen Projekten mit viel Fremdcode wäre dies eine echte Erleichterung.
