Interview mit Daniel Megert vom Eclipse-JDT-Team

Interaktiver IDE-Vergleich: Ergebnisse Eclipse

Auch Daniel Megert vom Eclipse-JDT-Team beantwortet in der letzten Runde unseres interaktiven IDE-Vergleichs zwischen Eclipse, NetBeans und IntelliJ IDEA Fragen aus der Community.

JAXenter: Diskutiert hatten Andreas Ender, Ralph, AK und Trepper darüber, ob die große Freiheit, die das Eclipse Plug-in-Konzept mit sich bringt, nicht in eine „Plug-in-Hell“ führt, in der eine stimmige Koordination der diversen Plug-ins unmöglich wird.

Und genau dass ist DAS Problem bei Eclipse! Für jede fehlende Funktionalität muss man ein Plugin irgendeines Autors verwenden das sich dann (oh Wunder) mit einem anderen Plugin nicht verträgt. Andreas Ender

Vor allem durch die verkürzten Release Zyklen werden ständig neue Konzepte integriert oder überarbeitet, so dass viele Plugins – und damit meine ich auch Eclipse-eigenen Plugins – nicht mehr richtig funktionieren. Ralph

Daniel Megert zu der Diskussion:

Daniel Megert: Für Plug-ins, die sich an die Spielregeln halten, ist das kein Problem. Leider halten sich selbst Plug-ins, die von der Eclipse Foundation angeboten werden, nicht immer daran. Der Release-Train, bei dem mittlerweile über 38 Projekte mitmachen, hilft, dieses Problem zu minimieren, und seit R3.4 sieht ein Plug-in-Schreiber dank den API Tools auch sofort, wenn er die Spielregeln nicht einhält. Sollte ein korrekt geschriebenes Plug-in, auf einem neuen Release nicht mehr laufen, so ist das ein Kontraktbruch durch die Plattform, der in einem Service-Release behoben werden müsste. Binäre Kompatibilität liegt uns am Herzen und ist ein wichtiger Bestandteil jedes unserer Releases.

JAXenter: David Linsin fragt nach dem SVN Support bei Eclipse:

Warum gibt es in der Standard Eclipse Version immer noch kein SVN Support? Warum muss ich mir das separat runterladen und kann nicht einfach loslegen? David Linsin

Daniel Megert: Dafür gibt es mehrere Gründe: Als wir das erste Eclipse Release veröffentlichten, wollten wir eine professionelle Java IDE mitliefern, und da gehörte ein SCM-Anschluss dazu. Zur damaligen Zeit war CVS das meist verwendete SCM in Open-Source-Projekten. Heute ist der Eclipse SDK Code immer noch in einem CVS Repository, und daher ist der CVS Support immer noch Teil des SDK’s. In Zukunft könnte ich mir eher vorstellen, dass auch der CVS Support herausgelöst wird, als dass wir noch SVN dazu nehmen. Dies auch, weil mit GIT schon das nächste SCM vor der Tür steht. Ich könnte mir auch vorstellen, dass die Foundation neben den bestehenden Download Packages auch solche mit SVN und/oder GIT Support bereit stellt.

JAXenter: Marc Teufel stellt zwei Fragen:

Warum bringt Eclipse nicht von Haus aus eine Maven-Integration mit, die so gut ist, wie die von Ant? Marc Teufel

Daniel Megert: Aus fast den gleichen Gründen, wie bereits oben erwähnt: Tools, welche wir selber benutzen, haben Priorität und zur Zeit verwenden wir im Eclipse SDK Maven nicht.

Gibt es Pläne über zukünftige Features, die das Entwickeln mit Java noch einfacher und besser gestalten sollen? Marc Teufel

Daniel Megert: Mit Java 7 werden direkt für Java selbst neue Verbesserungen kommen, welche wir natürlich in der Eclipse Java IDE unterstützen werden. Zudem möchten wir in Zukunft das Lesen von verschachteltem Code erleichtern, indem man zum Beispiel einfach erkennen kann, wenn Code falsch eingerückt ist. Daneben machen wir auch unsere existierenden Features, wie Content Assist, Quick Fixes und Refactorings immer smarter.

JAXenter: Für nero ist Eclipse schwergewichtig geworden. Er fragt nach möglichen Erleichterungen in e4:

Eclipse wird doch mehr und mehr zum Windows unter den IDEs [..]. Ich kenne v.a. viele PHP-ler, die Eclipse für viel zu schwerfällig halten. Kann man da nicht mal eine schlankere, agilere Version der Eclipse-IDE bauen? Wird das vielleicht im Eclipse e4 etwas entspannter? nero

Daniel Megert: Aus Sicht von JDT kann ich nicht beurteilen, ob der PHP Support zu schwerfällig ist, aber für JDT trifft es meiner Meinung nach nicht zu. Mit e4 nähert sich Eclipse vor allem dem Web und den Web-Technologien an. Der bestehende PHP Support wird dadurch nicht automatisch schlanker, ohne das Zutun der PHP Plug-in Provider. Aber ja, mit genügend Ressourcen kann man alles bauen 😉

Ich finde also ich nicht, dass Eclipse für den Benutzer von JDT schwergewichtig ist. Aber für Plug-in-Schreiber, und auch für uns Entwickler selber, wird der Code schwerer zu erweitern, da wir alle alten APIs erhalten müssen. In dieser Hinsicht gibt uns e4 die Freiheit, viele Altlasten loszuwerden.

JAXenter: Zum Abschluss nochmals Marc Teufel mit der Frage:

Wie läuft der Entwicklungsalltag bei Euch ab? Marc Teufel

Daniel Megert: Am Morgen schauen wir uns normalerweise zuerst die Resultate des nächtlichen Builds an und beheben allenfalls aufgetretene Probleme, was jedoch selten vorkommt. Danach schauen wir die Bugzilla Inbox an, wobei kleinere Bugs oft gleich geflickt werden. Nun wenden wir uns entweder den Features/Bugs zu, welche auf dem Milestone-Plan sind, oder machen Codereviews und Coaching von anderen Team-Mitgliedern oder externen Contributors. Je nach Situation praktizieren wir auch Test-First. Von Zeit zu Zeit schauen wir uns die Resultate der Performance-Tests an und reagieren gegebenenfalls darauf. Rund alle sechs Wochen testen alle einen ganzen Tag lang, um am Ende der Woche einen stabilen Milestone-Build abliefern zu können.

JAXenter: Vielen Dank an Daniel Megert für seine ausführlichen Antworten und natürlich auch an alle Kommentatoren für ihr Feedback!

Daniel Megert ist diplomierter Informatik-Ingenieur ETH und arbeitet bei IBM Research GmbH Zürich. Er ist Eclipse Project Committer der ersten Stunde und hat bei Komponenten wie Search, Text und JDT UI mitgearbeitet. Zurzeit ist er Eclipse PMC Mitglied und Eclipse JDT Co-Lead.
Geschrieben von
Kommentare

Schreibe einen Kommentar

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