Eclipse Magazin: Man hört gelegentlich, dass e4 vor allem ein Projekt sei, um Eclipse Runtime voranzutreiben, während Eclipse als IDE vollständig sei und nicht verändert werden sollte. Wie denkst du darüber?
Mike Wilson: Nun, davon bin ich etwas überrascht, um ehrlich zu sein. Zu behaupten, Eclipse sei als IDE komplett, ist genauso, als sagte man: "Im Bereich der IDEs wird nichts mehr passieren". Das kaufe ich wirklich niemandem ab! Ich sehe vielmehr, dass im IDE-Bereich zurzeit spannende Dinge passieren wie kollaborative Softwareentwicklung in Echtzeit und verteilten Entwicklerteams (z. B. Jazz, Google Wave, etc.), Multicore-Programmierung (besonders jetzt, da selbst Laptops schon vier oder mehr Kernprozessoren haben können), Multi-Language-/Multi-Target-Entwicklung, verteilte Builds, groß angelegte Systeme. Mann, die Zukunft sieht doch rosig aus für IDEs! Aber um diese neuen Entwicklungen angehen zu können, braucht es auch eine Architektur, die diese Dinge unterstützt. Einiges davon könnte sicherlich auch mit Eclipse 3.x umgesetzt werden, aber wahrscheinlich nicht schnell genug, um nicht von neuen Wettbewerbern überholt zu werden.
Eclipse Magazin: Im e4-Projektplan [5] findet sich die Aussage, dass Abwärtskompatibilität nicht im Hauptfokus von e4 liegt. Was sagst du Leuten, die sich Sorgen darüber machen, dass Eclipse 4.0 eine Gefahr für die Kohärenz der Eclipse-Plattform darstellen könnte.
Mike Wilson: Ich denke, es ist hier wichtig, zwischen dem e4-Incubator-Projekt (für das diese Aussage gilt) und der Menge von neuen Features zu unterscheiden, die wir mit der Version 4.0 des Eclipse SDK zur Verfügung stellen möchten.
Architektonisch ist e4 eine leichtgewichtige, servicebasierte Plattform mit einem höchst flexiblen, dynamisch aktualisierbaren UI-Modell, das viele Rendering-Technologien unterstützt. In anderen Worten: Die Interna sind nicht wirklich dieselben wie in Eclipse 3.x. Doch das Eclipse 4.0 SDK (das auf der Technologie von e4 basieren wird) wird alle API-konformen 3.x-Plug-ins ohne Änderungen sauber auf dem Desktop ausführen. Von meinem Standpunkt aus ist also die Kompatibilitätsaussage, die wir machen, dieselbe wie die, welche schon immer bzgl. der 3.x-Linie gemacht wurde. Und glaube mir: Um auf dieses Niveau zu kommen, wird es nötig sein, der Entwicklung des Kompatibilitäts-Layer eine wirklich sehr hohe Aufmerksamkeit zu schenken.
Dennoch bin ich mir durchaus darüber im Klaren, dass es da draußen Plug-ins gibt, die abhängig von internen Datenstrukturen, Methoden, Klassen usw. der Workbench sind. Die Chancen, dass diese Plug-ins auch in 4.0 problemlos weiterlaufen werden, sind niedrig. Ich schätze, das größte Kompatibilitätsargument ist also: "Stop_Using_Internals" – Hör auf, interne Strukturen zu verwenden!
Ich mache mir indes keine Sorgen, dass wir ein "Kohärenz-Problem" bekommen werden. Wie ich in meinem Blogeintrag sagte, glaube ich, dass sich die Verbreitung von e4 organisch vollziehen wird: Die Leute werden e4 einsetzen, um damit neue, interessante Dinge in bestimmten Bereichen anzustellen, und gleichzeitig aber noch viele Jahre lang Werkzeuge auf Basis der 3.x-Schiene nutzen. Auch wenn man dazu übergeht, "reine" e4-Plug-ins zu entwickeln (d.h. Plug-ins, die den Kompatibilitäts-Layer nicht benötigen), heißt das nicht, dass diese nicht mit den 3.x-Plug-ins zusammenarbeiten könnten - vorausgesetzt, es steht ein Kompatibilitäts-Layer zur Verfügung.
Eclipse Magazin: Im e4 White Paper von John Arthorne [6] werden sieben Hauptarbeitsgebiete von e4 genannt:
Steht dieser Architekturplan fest oder können wir hier noch mit Änderungen rechnen?
Mike Wilson: All diese Punkte sind dort aufgelistet, weil sie hoch genug auf jemandes Prioritätenliste standen, dass dieser bereit war, in die Implementierung seines Features zu investieren. Das ist wirklich die Natur eines Inkubationsprojekts, wie es e4 ja eines ist. Unter den genannten Punkten ist es wohl der neue SWT-Port, der am wenigsten Zugkraft entwickeln konnte: Es wurde zwar auch hier wirklich gute Arbeit geleistet, doch war es schwierig, Real-World-Code zu finden, der davon profitieren konnte. Auf allen anderen Gebieten scheint man aber gute Fortschritte zu machen.
Ich könnte mir schon vorstellen, weitere Punkte mit auf die Liste zu nehmen. Aber damit das zum gegenwärtigen Zeitpunkt passiert, müsste es glasklar feststehen, dass das neue Feature einen signifikanten Mehrwert bietet, zudem hervorragend zu den anderen Arbeiten passt und über eine starke Community verfügt, die sich um die Entwicklung bis hin zur Fertigstellung kümmert. Realistisch gesehen denke ich, dass es schwierig wäre, eine neues Feature noch ins erste Release im Juli 2010 mit aufzunehmen, selbst wenn sich die oben genannten Voraussetzungen zum jetzigen Zeitpunkt einstellen würden.
Eclipse Magazin: Gemäß e4-Projektplan werden zurzeit mehrere unterschiedliche UI Frameworks in e4 entwickelt. Können diese UI Frameworks nebeneinander existieren oder wird es an dieser Stelle nötig sein, eine Architekturentscheidung zu fällen?
Mike Wilson: Es gab über diesen Punkt eine gesunde Diskussion auf der e4-Dev-Mailing-Liste [8], aber ich denke nicht, dass die Frage schon endgültig geklärt ist. Meine persönliche Meinung dazu ist, dass es prinzipiell eine gute Sache ist, wenn einem Entwickler unterschiedliche Frameworks zur Verfügung stehen – solange er nicht dazu gezwungen wird, wirklich alle zu kennen, um seinen Job zu erledigen. Die Möglichkeit zu haben, zwischen verschiedenen Frameworks je nach vorliegender Problemdomäne auszuwählen, ist hervorragend. Solange es eine klare Trennung gibt, so dass dein Plug-in und mein Plug-in problemlos interagieren können, ohne dass wir wissen müssen, wie genau das jeweils andere Plug-in implementiert ist - wen kümmert es dann, welche Technologie verwendet wurde?
Eclipse Magazin: Wo steht ihr heute und welche Arbeit muss noch getan werden bis zum Eclipse 4.0 Release im Sommer 2010?
Mike Wilson: In der Zeit seit dem e4 0.9 Release (siehe [9]) haben wir an den finalen Versionen der internen Strukturen gearbeitet (z. B. den UI Modell-Klassen). Zudem haben wir die "Hacks" im Abwärtskompatibilitäts-Layer durch echten Code ersetzt, weitere Teile des JavaScript-Support implementiert, die Eclipse Application Services definiert und dokumentiert, an der CSS Engine und am SWT Widget Support gearbeitet, die UI Frameworks weiter verbessert und sogar einige Codeteile (z. B. die Arbeiten am flexiblen Ressourcen-Modell) in die 3.x-Linie übertragen.
Ich glaube, bis Ende Juli 2010 gibt es noch eine Menge zu tun, in allen Bereichen von e4 – und jede Unterstützung dabei ist herzlich willkommen! Wer daran interessiert ist, am Projekt mitzuarbeiten, kann sich einfach auf die e4-Dev-Liste eintragen und uns eine Mitteilung zukommen lassen!
Eclipse Magazin: Vielen Dank für dieses Gespräch!
Links & Literatur
- Mike Wilsons Blogeintrag „Eclipse has a Future“ zu e4
- "The 20 Things"
- e4-Sessions auf der EclipseCon 2008
- E4 Summit Ottawa
- Projektplan für e4 Version 0.9
- White Paper: „e4 Technical Overview” von John Arthorne
- Artikel „e4 Preview: User Interface Styling mit CSS“ von Kai Tödter aus Eclipse Magazin 5.09
- e4-Dev-Mailing-Liste
- e4 0.9 Release Notes
- e4 1.0 Milestone 1
