Daniel Megert im Gespräch über Eclipse und JDT

Interaktiver IDE-Vergleich: Teil 2 – Eclipse

Die Ursprünge von Eclipse liegen bei der Softwareschmiede Object Technology International (OTI) aus Ottawa, Kanada, die im Jahr 1996 von IBM übernommen wurde. Die Arbeiten des OTI-Teams, das bereits für die Smalltalk-basierte VisualAge-IDE verantwortlich zeichnete, an einer neuen, erweit

erbaren Entwicklungsplattform mündeten schließlich in die populäre Eclipse-Entwicklungsumgebung, die 2001 von IBM als Open-Source-Projekt freigegeben wurde und den Markt der IDEs seitdem entscheidend geprägt hat.

Für die Java-Entwicklung wurde das Eclipse Java-Development-Tools-(JDT-)Projekt aus der Taufe gehoben, das als erstes Anwendungsbeispiel für die grundsätzlich offene Eclipse-Plattform fungierte. Daniel Megert war von Anfang an im OTI-Entwicklerteam dabei und ist als Eclipse Project Committer der ersten Stunde und Co-Lead des Eclipse-JDT-Projekts prädestiniert dafür, in unserem interaktiven IDE-Vergleich die Eclipse-Position zu vertreten

JAXenter: Hallo Herr Megert. Worauf wurde bei der Entwicklung der Eclipse IDE und der Java Development Tools besonderen Wert gelegt?

Daniel Megert: Unser Ziel war es, eine betriebssystemunabhängige, erweiterbare Plattform für viele verschiedene Werkzeuge zu schreiben, welche gemeinsam darauf zusammenleben können und sich nahtlos integrieren. JDT war als erste exemplarische Anwendung auf dieser Plattform gedacht.

Hauptanliegen waren die Erweiterbarkeit durch sogenannte Extension Points und die Skalierbarkeit dadurch, dass ein Plug-in nur auf Verlangen geladen wird. Dabei war es uns ein großes Anliegen, dass die verschiedenen Komponenten nur über Eclipse APIs aufeinander zugreifen.

Es wurde großes Gewicht darauf gelegt, dass jedes Stück Code auch irgendwo benutzt wurde und dass man jeden Tag mit der neusten Version arbeitete, ganz nach dem Moto „eat your own dog food“. Beim Entwicklungsprozess wurde streng darauf geachtet, dass gemeinsam und offen geplant wurde und nach jedem sechswöchigen Meilenstein auch tatsächlich etwas Brauchbares und gut Getestetes abgeliefert wurde.

Durch Newsgroups und Bugzilla haben wir andere Teams innerhalb und ausserhalb IBM früh eingebunden, um direktes Feedback von unseren Benutzern zu erhalten. Dadurch waren wir gut vorbereitet, als das Projekt unter dem Namen Eclipse Open Source wurde. Unsere Erfahrungen haben wir genutzt, um eine große Community rund um Eclipse aufzubauen.

JAXenter: Wo liegen aus Ihrer Sicht die Stärken von Eclipse JDT gegenüber anderen IDEs?

Daniel Megert: Eine besondere Stärke liegt an der Fülle von Werkzeugen, die der Entwickler beim Schreiben von Code zur Hand hat: Da sind natürlich der kontextsensitive Content Assistant und viele wertvolle Refactorings, was die meisten IDEs bieten. Dazu kommen aber auch viele intelligente Quick Assists und Quick Fixes. Das Lesen von Code wird erleichtert durch Quick Outline und Quick Type Hierarchy sowie Code Hovers, mit denen man interagieren kann (z.B. im selben Javadoc Hover weiter navigieren).

Ein weiterer großer Vorteil ist der einzigartige inkrementelle Java Compiler (ECJ), welcher auch ausserhalb der IDE genutzt werden kann. Dieser erlaubt es auch, viel toleranter auf Typfehler im Code zu reagieren.

Natürlich spielt auch die Erweiterbarkeit und die große Community von Eclipse eine große Rolle: die Extension Points in Kombination mit den stabilen Eclipse APIs ermöglichen den Plug-in-Entwicklern, das bestehende System zu erweitern und erlaubt es, dass man aus einer riesigen Fülle von Plug-ins auswählen kann, wenn es darum geht, die eigene IDE zu erweitern. Dabei helfen die Eclipse API Tools, dass die API-Regeln beachtet werden.

Der Hauptvorteil ist jedoch, dass man all dies unter einer Open-Source-Lizenz nutzen darf und wegen der Produkt-freundlichen Lizenz (EPL) auch selber in eigene Produkte integrieren kann.

JAXenter: Was kann Eclipse im Gegenzug von anderen IDEs lernen?

Eclipse JDT fokussiert sich auf die reine Java-Entwicklung. Die Unterstützung von J2EE erfolgt durch andere Eclipse Plug-ins aus dem Eclipse-WTP-Projekt. Andere IDEs bieten J2EE-Unterstützung schon im Basisumfang an. Die Modularität von Eclipse hat Vorteile, kann aber dazu führen, dass es zwischen den einzelne Plug-ins Inkonsistenzen und verschiedene Ansätze zur Lösung von Problemen geben kann. Hier könnte sich noch einiges verbessern, so dass alle Einzelteile gewisse Qualitätsanforderungen erfüllen und besser aufeinander abgestimmt sind. Die Eclipse UI Guidelines sind ein wichtiger Schritt in diese Richtung.

JAXenter: Vielen Dank für Ihre Ausführungen! Jetzt warten wir auf die Fragen aus der Community!

Geschrieben von
Kommentare

Schreibe einen Kommentar

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