Eclipse 4.0 wird bekanntlich im Sommer 2010 erscheinen. Der Versionssprung auf die Nummer vier lässt aufhorchen: Mit Versionssprüngen dieser Art wird üblicherweise eine Komplettüberarbeitung eines Projekts assoziiert, die die niedrigere Version irgendwie alt und überholt erscheinen lässt.
Der Fall war das sicherlich beim Übergang von Eclipse 2.x auf Eclipse 3.0, als mit der Einführung des OSGi-Standards das "Killer-Feature" integriert wurde, das jedem 2.x-User den Umstieg schmackhaft machte - wer wollte denn damals nicht auf den OSGi-Zug aufspringen und auf lange Sicht auf dem 2.x-Abstellgleis landen? Doch wird Eclipse 4.0 ein ähnliches Killer-Feature enthalten, das die Augen aller Eclipse 3.x-Anwender zum Leuchten bringt?
Diese Frage wird unter den Eclipse-Committern und -Usern gerade heiß diskutiert. Elias Volanakis von EclipseSource vertritt in seinem Blog die Postition, dass die Technologien, die derzeit im e4-Inkubator entwickelt werden, zwar große Hoffnungen wecken, jedoch für die breite Masse der Eclipse 3.x-User (die durchschnittlichen Java- und Web-Entwickler) kaum von Interesse seien. Wird e4 zum Windows Vista von Eclipse?
Seine Argumente:
- e4 soll mit überflüssigem Ballast aufräumen und leichtgewichtiger daher kommen. Bisher würden sich die 230 MB des e4 Download-Pakets aber keineswegs schlanker anfühlen.
- Das e4-Programmiermodell, das ja auf Dependency Injection und Annotationen setzt, sei nicht einfacher, sondern schlicht nur anders. Die Entwicklung von Applikationen sei weiterhin ein (zu) anspruchsvolles Unterfangen. Es sei beim neuen Programmiermodell z.B. schwer zu erkennen, welche Annotationen zu einem gegebenen Zeitpunkt verfügbar seien.
- Und was könnte denn das zitierte "Killer-Fearture" in e4 sein?
- Die Download-Größe von 230 MB komme nur dadurch zustande, dass e4 bisher noch das 167 MB große 3.x-SDK mit sich herumschleppe, dazu noch EMF (27 MB) und Teile von WTP und GEF. Die reinen e4-Bundles kämen lediglich auf ultraschlanke 2 MB, mit Abhängigkeiten nur zu SWT, JFace, Equinox und der EMF Core Runtime. Auf lange Sicht soll Eclipse 4.0 den Ballast des 3.x-SDKs natürlich abwerfen.
- Zur Beantwortung der Frage nach dem Sinn von Dependency Injection verweist Bokowski auf John Arthornes Kommentare in einem Bugeintrag:
The purpose of injection was to make it easier to obtain services in the general case, as well as to decouple of service user from knowing or caring about who provided the service. John Arthorne
In einem Beispiel zeigt Arthorne, dass die Verwendung von Dependency Injection zu kürzerem und einfacher zu handhabenden Code führt. Doch letztlich scheinen sich hier gewisse Programmierschulen gegenüberzustehen, und die endgültige Entscheidung, ob Dependency Injection eine Vereinfachung bringt, scheint noch auszustehen bzw. an den persönlichen Vorlieben und Erfahrungen eines Entwicklers zu hängen.
- Die Frage nach dem Killer-Feature in e4 gibt Bokowski weiter an die Community. Für Kommentator und e4-Committer Kai Tödter besitzt e4 sehr wohl ein solches Killer-Feature, das viele Unternehmen davon überzeugen werde, auf die 4.x-Linie umzusatteln. Denn bisher war es schwierig bis unmöglich, RCP-Applikationen dem gegebenen Corporate Design eines Unternehmens anzupassen. Genau dieses Defizit habe aber den breiten Einsatz von Eclipse RCP in vielen Unternehmen verhindert.
The lack of customizing the look and feel (in terms of implementing a given visual design) in some cases has been a "killer feature" for not using RCP. Kai Tödter
Die Möglichkeit, das Look and Feel einer Eclipse-Anwendung einfach per CSS zu verändern, könnte leicht zu einer viel größeren Akzeptanz von Eclipse-Technologie im Enterprise-Bereich führen.
Und die Argumentation ist einleuchtend: Welcher Vertreter zeigt seinem Kunden schon gerne eine hässliche Tabellen-Anwendung, die so gar nicht sexy den Stil und das von der Marketing-Abteilung akribisch ausgetüftelte Lebensgefühl und Image eines Produkts vermittelt?
Gerade im Bereich des UI-Design stehen in e4 mit der Möglichkeit, Oberflächen deklarativ mittels XML (XWT: XML Windiowing Toolkit) und EMF (Toolkit Model) zu beschreiben, weitere interessante Ansätze bereit (siehe auch Artikel im Eclipse Magazin 5.09: "Vorschau auf e4: UI Styling mit CSS" von Kai Tödter, Eclipse Magazin 2.10: "Deklarative UIs in e4 - XWT versus Toolkit Model" von Marc Teufel, Yves Yang und Hallvard Traetteberg).
Und welches ist Ihr Killer-Feature in e4? Was sähen Sie gerne im Eclipse 4.0 SDK integriert?
