Hauptsache flott

Inhaltsverzeichnis

Es mag vielleicht überraschen, dass nicht die Unterstützung von Java 5.0, sondern eine bessere Performance zu den erstgenannten Zielen der Entwickler der neuen Eclipse-Release 3.1 gehört. Bedenkt man jedoch, dass alle Anwender von einem höheren Durchsatz profitieren, während nur wenige die Spracherweiterungen von Java 5.0 schon jetzt umsetzen können, erscheint der Projektplan in einem anderen Licht. Die Eclipse-Entwickler wollten auch dann eine ausreichende Verarbeitunggeschwindigkeit gewährleisten, wenn Anwender extrem hohe Anforderungen an die Workbench stellen. Auf der Eclipse-Homepage sind die beeindruckenden Ergebnisse der Optimierungen dokumentiert. Man kann diese auch innerhalb der Workbench verfolgen, sofern man das Performance-Monitoring aktiviert hat.

Um das Tuning zu erleichtern, haben die Entwickler die Klasse PerformanceStats eingeführt, die eine einfache Programmierschnittstelle für Messungen innerhalb von Eclipse-Anwendungen zur Verfügung stellt. Mit Hilfe des beim Milestone 4 vorgestellten Performance Views oder über ein entsprechendes Plugin (zum Beispiel von Kyrsoft, siehe Kasten „Infos im Web“), lassen sich Messwerte wie der Speicherverbrauch auch ohne einen externen Profiler visualisieren (Abbildung 1).

Tuning-Maßnahmen betreffen nicht nur den Hauptspeicherbedarf, sondern vor allem die Startgeschwindigkeit, die Geschwindigkeit beim Wechsel zwischen Workspaces und die bessere Skalierbarkeit. Aussagen und Messwerte sind selbstverständlich nicht generalisierbar, weil die Leistungsfähigkeit stark von der Konfiguration der Workbench und der Potenz des Rechners abhängt, auf dem Eclipse läuft. Testfälle lassen trotzdem eine deutliche Tendenz zum Besseren im Vergleich zur Vorversion erkennen.

Mehr Infos

Infos im Web

• Rund um die Eclipse-Performance
• Der Projektplan
  
• Eclipse-Memory-Monitor
  

Zum Beispiel konnte man durch Optimierungen am JDT-Core (Java Development Tools) den Start der Workbench um 50 Prozent beschleunigen. Ein weiterer wichtiger Punkt auf dem Arbeitsplan des Eclipse-Projekts war das Einlesen beziehungsweise der Wechsel des Workspaces. Für Entwickler, die ihre Projekte auf verschiedene Arbeitsbereiche verteilen und oft zwischen diesen wechseln, wollte man die Zeit für das Zurückschreiben und Einlesen des Workspace reduzieren. Auch hier gibt es deutliche Fortschritte: Das Hin- und Herschalten geht nun bis zu zehnmal schneller vonstatten als beim Vorgänger.

Module als Performance-Bremse

Obwohl es ein wenig paradox klingt, sorgten der modulare Aufbau von Eclipse und die damit verbundene einfache Erweiterbarkeit der Workbench gelegentlich für schlechte Performance. Manche Anwender installierten viele Plugins mit zahlreichen Views und Perspektiven und zwangen damit Eclipse 3.0 in die Knie. Oberstes Gebot war daher, die Geschwindigkeit der Workbench auch unter derart extremen Bedingungen wieder in den grünen Bereich zu bringen.

Wem das alles noch nicht ausreicht, der kann Eclipse oder damit erstellte Anwendungen nun auch ohne das native Startprogramm (Windows: eclipse.exe) aufrufen. Den Launcher zu umgehen und Eclipse direkt von der Kommandozeile zu aktivieren, ist bei der Verwendung eines externen Profilers oder bei Problemen mit dem Launcher oftmals sinnvoll. Dies geschieht durch das Starten des Startup-Archivs mit dem Java-Interpreter. Unter Windows beispielsweise: java -jar c:\programme\eclipse\startup.jar.

Etwas länger als die Kollegen, die mit anderen bekannten Entwicklungsumgebungen arbeiten, mussten sich Eclipse-Benutzer bis zum Erscheinen der zu Java 5.0 kompatiblen Workbench gedulden. Das lag vermutlich an den notwendigen gravierenden Änderungen, die sich durch die gesamte Eclipse-Basis, angefangen beim inkrementellen Compiler über das Build-Management und die Refactoring-Funktionen bis zum Editor mit dem Codeformatierer und den Programmierhilfen ziehen.

Der Java-Compiler beherrscht nun alle Spracherweiterungen von Java 5.0. Um die nutzen zu können, reicht es aus, die Workbench unter einer JRE 1.4 zu starten und die Projekteinstellungen auf Java 5.0 anzupassen (Abbildung 2). Will man die Programme jedoch ausführen, benötigt man die Laufzeitumgebung von Java 5.0 oder muss sich mit Tricks behelfen. Einer wäre, durch einen Compiler-Schalter dafür zu sorgen, dass der Compiler JRE-1.4-kompatiblen Code erzeugt. Danach müsste man noch die mit J2SE 5.0 neu eingeführten Klassen wie java.lang.Enum der Laufzeitumgebung bekannt geben.

Sowohl Compiler als auch Editor unterstützen generische Datentypen (Generics oder Klassenschablonen). Das bedeutet nicht nur, dass Syntaxeinfärbung und Codeformatierung mit den neuen Datentypen korrekt funktionieren, sondern auch, dass auf Tastendruck von Ctrl-Space (Code Assist) oder über F3 (Code Select) eine Programmierhilfe erscheint. Ebenfalls angepasst hat man die Views und einige Dialoge sowie die Refactoring-Funktionen, die nun auch mit diesen Datentypen zurecht kommen.

Mit freundlicher Hilfe vom System

Erweiterte Schleifen erkennt der Editor und färbt die Syntax korrekt ein. Im Fehlerfall bietet er eine Programmierhilfe und einen Quick Fix an. Letzterer macht Verbesserungsvorschläge und assistiert dem Programmierer dabei, das Problem soweit einzugrenzen, dass der Code frei von Fehlern und Warnungen ist oder automatisch auf einen neueren Stand (etwa Java 5) migriert wird. Wer alte Schleifen zum neuen Typ konvertieren möchte, erhält auf diese Weise ebenfalls Unterstützung. Für den neuen typsicheren Aufzählungstyp (Enum) gibt es neben der obligaten Syntaxhervorhebung einen Assistenten, der beim Anlegen einer Enum-Klasse hilft.

Das Schlüsselwort Enum erkennt die Workbench übrigens auch dann, wenn die Projekteinstellungen nicht auf Java 5.0 gesetzt sind. In diesem Fall warnt sie, dass seine Verwendung zu Konflikten mit späteren Java-Versionen führen könnte. Weiterhin wichtig sind statische Importe, die der Entwickler überall dort anwenden sollte, wo er kurzen und besser lesbaren Quelltext erzielen möchte. Für dieses Sprachkonstrukt mussten nicht nur wie bei den anderen Spracherweiterungen Syntaxhervorhebung und Programmierhilfe angepasst werden, sondern auch die Suchfunktion der Workbench.

Neben den bisher beschriebenen Verbesserungen kann Eclipse 3.1 mit einer Reihe weiterer aufwarten. Sie reichen von eher kosmetischen Eingriffen, etwa neuen Symbolen, bis zu inhaltlich relevanten Funktionen. Wer Projekte importieren will, kann dies jetzt auf verschiedenen Wegen tun. Überaus praktisch ist die in Milestone 4 eingeführte Funktion, mit der man Java-Projekte, die in einem beliebigen Verzeichnis liegen dürfen, suchen und importieren kann. Eine andere neue Möglichkeit ist, Projekte aus Archiven in den Workspace einzulesen. Die Im- und Exportfunktionen erlauben jetzt auch das tar.gz-Format. Der entsprechende Wizard trägt den Titel „Export Archive File“.

In Sachen Teamarbeit gibt es erfreuliche Neuigkeiten zu melden: Den in die Workbench integrierten CVS-Client hat man überarbeitet. Betroffen davon ist zum Beispiel der Commit-Dialog, der jetzt eine Liste von Dateien anzeigt, auf die ein Commit ausgeführt wird. Beim Zurückschreiben von Dateien bisher unbekannten Typs erhält der Anwender bei dieser Aktion die Möglichkeit, den Dateityp zu spezifizieren. Der Missstand, dass ein nicht näher beschriebener Dateityp undifferenziert als Binary eingecheckt wird und sich später schlecht zuordnen lässt, ist somit abgestellt.

Wer seine Anwendung mit Hilfe von Ant ausliefert, darf sich darüber freuen, dass Eclipse nunmehr das relativ aktuelle Ant 1.6.2 enthält, und dass er Ant-Skripte mit Hilfe des integrierten Debuggers testen kann. Dazu reicht es aus, wenn der Entwickler - wie bei der Java-Programmierung - in der XML-Datei einen Breakpoint setzt und das Skript im Debug-Modus startet. Der Editor ist jetzt in der Lage, Abschnitte in Ant-Skripten zu falten und zu expandieren sowie den Code zu komplettieren. Zusätzlich enthält er einige mehr oder weniger wichtige kosmetische Änderungen. Codeteile expandieren und falten konnte schon Eclipse 3.0. Die zugehörigen Symbole sahen denen für eine überschriebene Methoden allerdings ziemlich ähnlich. Aus diesem Grund arbeitet der Editor nun mit den allgemein gebräuchlichen Plus- und Minus-Symbolen.

Fazit

Der harmlos erscheinende Sprung der Versionsnummer von 3.0 auf 3.1 täuscht. Die Änderungen durch die Umstellung auf Java 5.0 und das dringend erforderliche Performance-Tuning sind tiefgreifender als man auf dem ersten Blick sieht. Bei der Arbeit mit der generalüberholten Java-Workbench zeigt sich, dass der große Aufwand und die lange Projektlaufzeit Früchte getragen hat: Eclipse bewegt sich wieder auf der Höhe der Zeit und das viel schneller als zuvor.

Bernhard Steppan
arbeitet als Softwareentwickler und freier Autor in Bad Homburg.

Literatur

[1] Bernhard Steppan; Entwicklungsumgebung; Sunblocker; Eclipse 3.0 Beta: Viele Detailverbesserungen; iX12/2003, S. 48

Mehr Infos

Eclipse und der Rest

Mit konkurrierenden Entwicklungsumgebungen wie Microsofts Visual Studio, Suns Netbeans und Borlands JBuilder hat Eclipse viel gemeinsam. Alle genannten Werkzeuge erlauben es, Produkte fremder Hersteller über eine Plugin-Schnittstelle zu integrieren. Zum Beispiel lassen sich auf diese Weise Versionskontroll- oder UML-Modellierungswerkzeuge andocken und die Umgebungen beliebig erweitern oder abspecken.

Alle Produkte sind integrierte Entwicklungsumgebungen (IDE) wie sie Borland mit Turbo Pascal erstmals eingeführt hat. Der Entwickler muss nicht zwischen verschiedenen Einzelwerkzeugen wechseln, sondern arbeitet mit aufeinander abgestimmten Programmen. Projektverwaltung, Debugger, Editor, Softwareverteilung, Versionskontrolle und Hilfesystem wirken bei diesem Konzept wie aus einem Guss.

Mit Visual Studio besitzt Eclipse die größte Schnittmenge. Beide Umgebungen bieten nicht nur eine mehr oder weniger komplette Entwicklungsumgebung an, sondern eine Tool-Plattform, die es erlaubt, verschiedene Werkzeuge zu integrieren und mit unterschiedlichen Programmiersprachen zu arbeiten.

Trotz vieler Ähnlichkeiten unterscheidet sich Eclipse deutlich von allen Konkurrenzprodukten in Bezug auf den Grad der Modularisierung (Plug-ins), die unterstützten Programmiersprachen und die verwendeten Java-Bibliotheken wie das GUI-Framework SWT. Die Auswirkungen eines durchdachten Plug-in-Konzepts zeigen sich besonders deutlich bei unterschiedlichen Aufgaben wie Rich-Client- und Webentwicklung oder bei der Arbeit mit mehreren Programmiersprachen.

Keine Programmierumgebung ist in der Lage, sich so chamäleonartig über Plug-ins, Views und Perspektiven an die individuellen Bedürfnisse anzupassen und bietet eine derart komfortable grafische Oberfläche. Seine Vorreiterrolle als Integrationsplattform für Werkzeuge aller Art wird das Eclipse-Projekt mit dem Release 3.1 und der Web Tools Platform (WTP) weiter ausbauen (siehe Artikel Seite 50 im aktuellen Heft).

(jd)