Die Liste aller kleinen neuen Features aus dem rund 85 MB großen SDK [1] auflisten zu wollen, würde in einer monotonen Sammlung von Fakten enden. Die gute Nachricht für alle 2.1er-Entwickler: Auf den ersten Blick hat sich gar nicht so viel verändert und doch ist ein Upgrade auf die neue Version empfehlenswert. Die gute Nachricht für alle Neulinge: Es gab nie zuvor so viel Hilfe für den Einstieg in Eclipse, wie mit Version 3 mitgeliefert wird.

Führt ein gutes Aussehen zu einem guten Gefühl?

Als wesentlichste Neuerung wird der erfahrene Eclipse-Benutzer das neue Look & Feel empfinden, das natürlich bei Bedarf auch deaktiviert werden kann. Ansonsten finden sich in Eclipse die alten Bekannten, der Editor, die Views, alles an seinem Platz und allerhöchstens farblich eine neue Gaumenfreude. Etwas flexibler geworden ist in diesem Zusammenhang allerdings die Positionierung der Views in der GUI.
Wer intensiv mit Eclipse als Java-IDE arbeitet und sich sehnlichst das eine oder andere zusätzliche Schmankerl gewünscht hat, könnte mit Eclipse 3 zusätzlich positiv überrascht werden. Besonders allerdings für Neulinge lohnt sich jetzt der Einstieg, denn ein großer Willkommenspictureschirm und so genannte Cheats, kleine Tutorials, anhand derer man sich durch unterschiedliche Aufgabenbereiche führen lassen kann, machen Laune, Eclipse für sich als IDE zu entdecken.

Neues vom Editor

Wer bisher dachte, ein Editor sei großes Textfeld mit Zeichen, die man bei Bedarf noch einrücken kann, hat weit gefehlt. Moderne Editoren müssen nicht nur automatische Syntaxprüfung während der Codeeingabe und farbliche Untermalung von Kommentaren beherrschen. Sie sind zentrale Eingabestelle und jede Aktion, die den Prozess hier beschleunigt, erhöht auch die Freude an der Entwicklung an sich.
So führte Eclipse mit Milestone 9 kurz vor der Fertigstellung das aus NetBeans 3.6 und Microsoft .NET bekannte Sourcecode-Folding ein, mit dem Teile des Source zwecks Übersichtlichkeit zusammengeklappt werden können. Neben neuen Quick-Fixes zum Beheben von Syntaxfehlern findet sich hier nun auch ein Tracing-Mechanismus (Quickdiff), der geänderte Source-Zeilen anzeigt und eine Mark occurrences-Funktion, die auf Wunsch das Vorkommen einer lokalen Variable in einer Methode, Exceptions oder Return Statements durch einfachen Mausklick signalisiert. Ähnliches vollführt das so genannte Semantic Highlighting jetzt in Eclipse 3.
Sehr angenehm ist auch, dass überschriebene Methoden mit einem kleinen Dreieck am linken Rand markiert werden, ohne andere Views für die Frage der Vererbungshierarchie bemühen zu müssen.

Besonders in Richtung Formatierung des Source hat Eclipse endlich auch die Sun Code Conventions erlernt, die natürlich individuell anpassbar sind und damit den leidigen, primitiven Code Formatter ablösen. Der Formatter interessiert sich dabei u.a. jetzt auch für die Einrückung Ihrer Javadoc-Kommentare, wenn Sie wünschen, auch um die Rechtschreibung innerhalb Ihrer Texte und bei einer sehr restriktiven Compiler-Einstellung gibt's gleich eins auf die Finger, wenn der Kommentar falsch gefüllt ist.

Überhaupt ist der Editor nochmals besser geworden und sieht sich inzwischen auch in der Lage, beim Kopieren von Sourcecode aus einer Klasse in eine andere die Import-Statements automatisch einzufügen, ohne dass es der Entwickler befiehlt. Wer mehrere Editorfenster gleichzeitig offen hat, gewinnt durch eine Auflistung verborgener Fenster das Gefühl für die Anzahl und die Inhalte der offenen Dateien zurück.

Neben einer ganzen Reihe von neuen fingerbrechenden Tastenkombinationen, die man eingeben und definieren kann (Eclipse bietet hier inzwischen die Hilfestellung, Ihnen komplexe Tastenkombinationen bei der Eingabe vorzuschlagen), definiert Eclipse neue Views für die tägliche Arbeit, z.B. Anzeige von Aufrufhierarchien, Darstellung des Javadoc zum aktuell selektierten Element oder Informationen über den aktuellen Bearbeitungsfortschritt.

Hintergrundprozesse und Fortschrittsanzeigen

Besonders bei großen Sourcecode Compiles oder langen Suchanfragen konnte man bisher getrost zur Kaffeetasse greifen und gebannt auf den Fortschrittsbalken von Eclipse schauen. Eclipse 3 hat inzwischen die saubere Verarbeitung von Hintergrundprozessen erlernt, dafür schmückt es die Informationen über seine aktuellen Aktivitäten mit einer zusätzlichen Progress-Anzeige, die detailliert über den Fortschritt informiert.

Ganz allgemein gewinnt man den Eindruck, Eclipse hat an vielen Stellen auch an Tempo dazu gewonnen, Referenzsuchen in großen Baumstrukturen, Compile-Abläufe ... vieles läuft schneller und runder. Neu gestaltete Views z.B. für die Anzeige von Suchergebnissen, die jetzt in Package-Baumstruktur erfolgt, sind dabei die Tüpfelchen auf dem i.
Die Suche von Objekten und Textstellen wurde inzwischen auf die Verwendung von Regular Expressions erweitert, in fast allen Dialogen stehen nun Code Completion-Mechanismen zur Verfügung, wenn einem z.B. der voll qualifizierte Name seiner Lieblingsklasse gerade entfallen ist. Beides aus meiner Sicht Features, die auch dringend notwendig waren.

Vorlagen, wohin das Auge reicht

Es mag nicht jedem Entwickler auffallen, aber auch die Definition von Templates wurde verbessert und Eclipse kennt inzwischen auch Vorlagen für Getter- und Setter-Methoden. Zudem scheint Eclipse 3 durch die Einführung von Variablen an etlichen Stellen an Flexibilität gewonnen zu haben. Neben Ressourcen, die unter einem logischen Namen verbunden waren (z.B. Root-Verzeichnisse, die pro Entwickler unterschiedlich lauteten) kann Eclipse nun auch mit selbst definierten Library-Sets, also Mengen von JARs unter einem logischen Namen, aufwarten. Bei der Definition von externen Programmen, die in der IDE gestartet werden sollen, hilft Eclipse mit einer breiten Latte an Variablen, um auf Verzeichnisse oder Projekte in Eclipse referenzieren zu können und bietet eigene Ant-Tasks an, um beim Build-Prozess Kontakt mit der IDE aufnehmen zu können, um z.B. den inkrementellen Build von Eclipse statt den puren Javac zu verwenden.

Projekte/Workspaces/Launch Configurations

Die Anwendung von Build- und Runtime-Konfigurationen ist seit jeher sicher eine der flexibelsten Stellen in Eclipse. Compile und Runtime sind faktisch komplett voneinander getrennt und komplexe Baumstrukturen von aufeinander verzweigenden Projekten und Klassenpfaden ermöglichen es, die Java VM, ihre Konfigurationsparameter, ihre Runtime Libraries, die Projekte, die Class Files, deren Sourcen und Bibliotheken beliebig komplex zu verdrehen und dies zur Build- wie auch zur Laufzeit.
In diesem Bereich zeigt Eclipse 3 nochmals Detailverbesserungen z.B. bei der Definition von userdefinierten Klassenpfadteilen oder der separaten Erstellung von Umgebungsvariablen unabhängig von der Maschine, auf der die VM läuft - natürlich alles verknüpft mit der Einbindung und Verwendung interner oder eigener logischer Namen in Eclipse.

Auch ist neben dem Ausschluss von Source-Teilen, die nicht kompiliert werden sollen, endlich, wie auch in Ant Compiles üblich, ein explizites Definieren von einzuschließenden Klassen möglich geworden. Damit der Entwickler bei der Menge an Konfigurationen nun den Überblick nicht verliert, erlaubt Eclipse 3 die Definition von Favorites, in welcher Konfiguration die Anwendung quasi am liebsten läuft.
Eclipse selbst beharrt inzwischen nicht mehr darauf, stets mit dem gleichen Workspace, als dem unterliegenden Verzeichnisbaum für die Projekte und Metadaten, arbeiten zu wollen. Was bisher per Startparameter übergeben werden konnte, wird jetzt per Dialog beim Start abgefragt. Welchen Teil der Festplatte wollen wir denn heute bearbeiten?

Debugging-Features

Da die Qualität und Mächtigkeit des Debug-Vorganges nicht selten von der genutzten virtuellen Maschinen, dem Hersteller und der Version abhängt, sind einige Features von jeher in Eclipse implementiert gewesen, die dann aber gar nicht nutzbar waren. So lässt sich meines Erachtens auch darüber diskutieren, ob neben einem Statement Breakpoint mit Bedingungen separate Methoden- und Classloading Breakpoints notwendig sind; aber immerhin in Eclipse 3 sind sie jetzt möglich. Des Weiteren unterstützt der Debugger mit neuen Pop-ups den Fehlersuchprozess, um die Struktur von Variableninhalten zu verdeutlichen.

Release-Sprung, dass ich nicht lache ...!?

Man kann darüber streiten, ob die reine Aufzählung neuer Features gleich einen Release-Sprung von 2.1 auf 3.0 notwendig macht. Schaut man allerdings unter die Motorhaube von Eclipse 3 - und das gilt vor allem für Plugin-Entwickler - macht sich an etlichen Stellen Verwunderung breit, die einen Versionssprung legitim erscheinen lässt.
Das bisherige proprietäre Plugin- und Featurekonzept weicht zunehmend der Vereinheitlichung mit der OSGi-Spezifikation [2], die u.a. das Management von Komponenten untereinander und die Schnittstellen definiert. Hier brechen neue Zeiten für die Definition von Plugins an.

Die bisherigen IDE-Plugins sind teilweise neu strukturiert worden, um höhere Wiederverwendung zu erreichen. Herauskristallisiert hat sich die so genannte Rich Client Platform (RCP) [3], die in der Abpictureung 5 dick umrandeten Teile des Gesamt-Eclipse-SDKs (UI, JFace, SWT und Runtime). Sie umfasst eine Menge von Plugins, die Entwicklerteams animieren sollen, auf Eclipse-Plugins aufbauend eigene Rich Clients zu entwerfen, die nichts mit Softwareentwicklungstools zu tun haben, sondern eine Art Framework bieten, um eigene Business-Frontendapplikationen zu erstellen. Insgeheim geht der IBM-Traum dann wohl auch hin zu einer SWT/JFace/RCP-Welt von Clients, die mit den WebSphere-Servern im Hintergrund als großem Bruder kommunizieren. Vielleicht zurecht gibt es hier Verfechter, die nach Sinn und Zweck von J2EE-Technologien fragen, wo das Plugin-Konzept von Eclipse an manchen Stellen fast ausgereifter für komplexe Business-Anwendungen erscheint.

In den Eclipse-Downloads finden sich denn auch separate Pakete für diesen RCP-Teil des Gesamt-SDKs, die selbst mit Source rund 17 MB umfassen und als Binärpaket nur gut 5 MB groß sind, je nach Zielbetriebssystem.
Für einige Pluginentwickler dürfte die Version 3.0 trotz Kompatibilitäts-Plugins, Abwärtskompatibilität zwischen Features und OSGi Bundles und Upgrade-Support durch Assistenten dennoch auch diesmal wieder böse Überraschungen bereithalten. Wo ist meine Eclipse-Klasse, wie heißt die Methode jetzt, wohin ist der XML-Parser verschwunden?
Immerhin schenkt Eclipse 3 dem Plugin-Entwickler dafür den Plugin-JUnit-Test und die Menge der berühmten kleinen Plugin-Wizards, um seinen Job zu erledigen.

Ant, CVS und sonstiges?

In die Menge aller neuen Features reihen sich natürlich u.a. auch kleinere Updates beim Thema CVS-Konfiguration und Ant-XML-Editor-Support ein sowie ein endlich aufgeräumterer Preferences-Dialog. Eclipse-Experten wissen vermutlich, worum es geht. Alles aufzuzählen sprengt den Rahmen dieses Artikels. Nicht umsonst gibt es viel Literatur bereits jetzt zum Thema Eclipse 3.0, die u.a. über die Fülle neuer Funktionen berichtet. Manches in den Bücherregalen dürfte allerdings auch schon wieder veraltet sein, nachdem sich die Eclipse-Entwickler in den letzten Milestones dieses Jahres noch mal richtig ins Zeug gelegt haben, vor allem, um Eclipse eine neuen Oberfläche zu verpassen.

Für den normalen Entwickler, der Eclipse bisher als gute bis hervorragende Java-IDE für seine Zwecke eingesetzt hat, sind die neuen Features unter Umständen dennoch nicht Grund genug fürs Upgrade. Es gibt einen ersten Support für JDK 1.5, der mit Milestone 9 in Eclipse realisiert wurde, aber die essenziellen Basisfeatures haben sich nicht geändert. Noch immer ist kein vernünftiger Makroeditor vorhanden, noch immer gibt's keinen GUI-Editor oder Support für Application Server.

Enttäuschung auf ganzer Linie?

Aus meiner Sicht: nein, denn Eclipse hat ganz deutlich an Feature-Reichtum und auch wirklich sinnvollen Erweiterungen dazu gewonnen. Was man von der reinen Eclipse-Entwicklungsumgebung separat betrachten muss, ist die Arbeit in der extrem starken Eclipse-Community und den dort entwickelten Erweiterungen (wir berichteten darüber [4]): den Eclipse-Tools und Eclipse-Technology-Projekten [5].
Besonders bei den Tools hat sich hier in letzter Zeit Erstaunliches getan, hat man doch begonnen, für die Entwicklung von Webanwendungen ein Eclipse-Web-Tools-Platform-Projekt anzugehen und den aus dem WebSphere Studio bekannten Visual Editor [6] zum Entwurf von Swing und SWT-GUIs der Öffentlichkeit in einer ersten Milestone 1-Version für Eclipse 3 an die Hand zu geben.

Überhaupt ist hier viel Bewegung drin, angefangen von der Unterstützung für UML 2-Meta-Modellen in Eclipse bis hin zur Weiterentwicklung des bereits legendären AspectJ und AJDT [7], dem Tool-Plugin zur Unterstützung von aspektorientierter Softwareentwicklung. Nicht zu unrecht wird AOP große Chancen für eine sinnvolle Ergänzung von objektorientierter Softwareentwicklung u.a. als J2EE/EJB-Alternative eingeräumt. Eclipse bietet hier heute schon recht gute Unterstützung. Mit dieser Aufzählung seien aber nur zwei von vielen Projekten genannt.
Viele Entwicklungsprojekte stellen Tools und Unterstützungs-Plugins für die Arbeit mit ihren Frameworks und Applikationen zur Verfügung. Angefangen von Tomcat- und Struts-Plugins für Webdeveloper über Alternativtechnologien für die Entwicklung von Enterprisesystemen wie dem Spring-Framework [8], J2EE-Support mittels der kostenlosen JBoss-IDE bis hin zu Datenbankmanagementtools, die heute weit mehr können als die rudimentäre DML mit Insert, Update und Delete beherrschen.

Kommerzielle Produkte wie beispielsweise MyEclipse [9] oder Omondo haben den Sprung in die Eclipse Version 3.0 bereits vollführt oder liegen in den letzten Zügen, um ihre Version kompatibel zu machen, Open-Source-Plugins sind häufig auf dem Wege zur 3.0er-Version.

Einsteigen? Upgraden?

Aus meiner Sicht kann die Frage mit einem klaren Ja beantwortet werden, so denn terminliche Engpässe oder Aufwandsfragen dem nicht im Wege stehen. Hat man alle Plugins, die man benötigt, in einer 3.0-kompatiblen Version vorliegen, heißt es eigentlich nur noch, sich der neuen Funktionen zu erfreuen. Im Wunderland der kostenlosen IDEs steht die preisliche Attraktivität doch sowieso außer Frage, oder?
Lars Wunderlich arbeitet als Systemarchitekt und Software Engineer im Bereich der Entwicklung von Unternehmensanwendungen mithilfe der J2EE-Technologie bei der TUI InfoTec GmbH & Co. KG. Er ist Co-Autor eines im Software & Support-Verlag erscheinenden Eclipse-Buches, das Eclipse 3.0 in seinen unterschiedlichen Facetten in der professionellen Softwareentwicklung ausführlich vorstellt.

Links und Literatur

• [1] www.eclipse.org/downloads/
• [2] www.osgi.org/resources/spec_download.asp
• [3] dev.eclipse.org/viewcvs/index.cgi/~checkout~/org.eclipse.ui.tutorials.rcp.part1/
  html/tutorial1.html
• [4] Lars Wunderlich: Eclipse vs. NetBeans, Eclipse und NetBeans im Entwicklungsprozess, in Java Magazin 5.2004
• [5] www.eclipse.org/projects/main.html
• [6] dev.eclipse.org/viewcvs/indextools.cgi/~checkout~/vep-home/main.html
• [7] dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/org.eclipse.ajdt/main.html
• [8] www.springframework.org/
• [9] www.myeclipseide.com/