JAXenter: Hallo Herr Bokowski! Sie stellen im Rahmen des Eclipse Platform Day auf der JAX die neue Eclipse-Generation e4 vor. Wie wird e4 die Eclipse-Plattform stärker machen?

Boris Bokowski: Erstens wird die Entwicklung von UI-Komponenten einfacher – durch das neue Programmiermodell basierend auf Dependency Injection und Services, durch die Möglichkeit, UI-Komponenten mit XWT deklarativ zu erstellen, und durch die Unterstützung von OpenSocial Gadgets als vollwertige Views in Eclipse. Zweitens bietet e4 vor allem mehr Flexibilität – durch das zugrunde liegende EMF-Modell, das das Zusammensetzen von Komponenten zu Anwendungen einfacher macht, und durch das CSS-basierte Styling, mit dem Eclipse-basierte Anwendungen nicht mehr wie die Eclipse IDE aussehen müssen.

JAXenter: "Adopting e4" heißt ihr Vortrag auf dem Eclipse Platform Day. Worauf kommt es bei der Einführung der neuen Technologien für Eclipse 4.0 an?

Boris Bokowski: Die Antwort hängt davon ab, welche Art von Eclipse-basierter Software man entwickelt. Am einfachsten ist die Situation für neue RCP-Anwendungen – hier lohnt es sich zu erwägen, ob man gleich auf e4-Basis entwickeln kann. Vorteile sind größere Flexibilität und besserer „Look“ sowie schnellere Ergebnisse dank des neuen Programmiermodells. Schwieriger ist es für existierende RCP-Anwendungen. Die Frage ist, ob sich der Portierungsaufwand lohnt, etwa wenn das Aussehen der Anwendung dem Kunden wichtig ist. Am wenigsten eignet sich e4 für die Entwicklung von Anwendungen oder Plug-ins, die nicht nur die Plattform verwenden, sondern auch UI-Komponenten von anderen Eclipse-Projekten. Weil diese anderen Projekte noch nicht so vorliegen, dass man sie direkt auf der „nativen“ e4-Plattform verwenden kann, bleibt eigentlich nur abzuwarten, bis das der Fall ist.

Auf jeden Fall würde ich empfehlen, bei der Entwicklung neuer Komponenten e4 von Anfang an im Hinterkopf zu behalten. Weil typische e4-Komponenten viel weniger Abhängigkeiten zum Framework haben, ist es relativ leicht, sich die spätere Portierung einfach zu machen. Mehr Details dazu in meinem Vortrag...

JAXenter: Sie stellen in einer zweiten Session auch die Integration von OpenSocial Gadgets in Eclipse vor. Was hat es mit OpenSocial Gadgets auf sich und warum beschäftigt sich das e4-Team damit?

Boris Bokowski: Das Web und insbesondere Web-basierte UIs werden immer wichtiger. Sicher werden Rich Clients auch langfristig noch eine wichtige Rolle spielen, aber es besteht die Gefahr, dass wir uns mit der Eclipse-Plattform in eine Sackgasse begeben, wenn wir sie nicht für Web-Technologien öffnen.

Grundsätzlich gibt es zwei mögliche Wege, Eclipse und Web einander näher zu bringen: Zum einen kann man versuchen, so etwas wie die Eclipse-Plattform oder das RCP-Framework im Browser laufen zu lassen. Das RAP-Projekt verfolgt diesen Ansatz und realisiert relativ erfolgreich Single Sourcing. Prinzipbedingt gibt es hierbei jedoch Einschränkungen, beispielsweise bei der Skalierbarkeit.

Das e4-Projekt verfolgt einen anderen Weg und ermöglicht es, Web-UI-Komponenten im Eclipse-Client einzubetten. Das Browser-Widget von SWT ermöglicht dies schon heute und eröffnet interessante Perspektiven. Bisher ist aber relativ viel „Handarbeit“ nötig, um Web-UI-Komponenten in Eclipse zu verwenden.

Neu in e4 ist die Möglichkeit, OpenSocial Gadgets direkt als Views in Eclipse zu öffnen. Die OpenSocial-Gadgets-Spezifikation, die schon von iGoogle, XING, MySpace und vielen anderen sozialen Netzwerk-Anbietern implementiert wurde, ist ein Standard, wie man Web-UI-Komponenten definiert. Für OpenSocial Gadgets, die im Eclipse-Kontext ablaufen, werden wir optional zusätzliche JavaScript-Schnittstellen anbieten, um die Integration in Eclipse zu verbessern. Dabei geht es zum Beispiel darum, dass OpenSocial Gadgets in Eclipse auf die aktuelle Selektion reagieren können, oder selbst die aktuelle Selektion bereitzustellen.

JAXenter: Wie weit sind die Arbeiten an e4 schon fortgeschritten? Wie wird das Eclipse SDK 4.0 aussehen?

Mit dem kürzlich fertig gestellten Milestone 5 sind wir endlich so weit, dass wir das e4-basierte Eclipse SDK für die weitere Entwicklung verwenden können – wir nennen das „Self-Hosting“ oder auch „Eating your own dog food“. Damit haben wir ein wichtiges Teilziel der Entwicklung erreicht. Konkret wird das Eclipse 4.0 SDK aus den folgenden Teilen bestehen:

• Erstens e4 als Basisplattform, aufbauend auf Equinox, SWT und JFace,
• zweitens die Kompatibilitäts-Schicht, die das API der Eclipse 3.x-Workbench unter Verwendung von e4 implementiert, und
• drittens der unveränderte Rest des Eclipse 3.6 SDKs – also z.B. die Komponenten Debug, JDT, PDE und so weiter.

Aus der Sicht von Endanwendern wird sich das Eclipse 4.0 SDK nur äußerlich geändert haben, durch das CSS-basierte Styling. Hoffentlich unsichtbar für Endanwender wird sich die komplette interne Implementierung der Workbench geändert haben. Dabei lässt es sich wahrscheinlich nicht vermeiden, dass sich ganz in der Tradition von x.0-Releases einige wenige neue Bugs einschleichen. Aus diesem Grund wird das Eclipse 4.0 SDK in diesem Jahr auch noch nicht Teil des jährlichen Release-Trains und nicht der empfohlene Download für die breite Masse der Eclipse-Anwender – das ist erst für Juni 2011 geplant.

Wir sehen das Eclipse 4.0 SDK als ein Release für Early Adopters und für die anderen Eclipse-Projekte. Unser Ziel ist ein solider Release Train in 2011 auf der Basis des Eclipse 4.x SDKs.

JAXenter: Und wann dürfen wir mit dem Release von Eclipse 4.0 rechnen?

Boris Bokowski: Der Release-Termin ist nach wie vor Ende Juli 2010. Wie schon gesagt werden die restlichen Eclipse-Projekte nicht genügend Zeit zum Testen gehabt haben, um sicherzustellen, dass sämtliche Plug-ins auch auf 4.0 einwandfrei laufen. Das betrifft vor allem solche Plug-ins, die nicht nur die öffentliche API, sondern auch interne Schnittstellen der Workbench verwenden.

Zu diesem Thema gab es kürzlich auch eine Diskussion auf der Mailingliste, ob die Versionsnummer „4.0“ wohl angemessen ist. Es ist schwierig, mit einer einzelnen Versionsnummer auszudrücken, wie sich 4.x und 3.x zueinander verhalten. Aus technischer Sicht hat sich am Eclipse 4.0 SDK so viel geändert, dass eine neue Versionsnummer „vor dem Komma“ gerechtfertigt ist. Aus pragmatischer Sicht hoffen wir, dass die Mehrheit der Endanwender nicht auf 4.0 umsteigt, bevor die existierenden Plug-ins genügend getestet worden sind. Unser Vorbild für den Umstiegsprozess ist die Ablösung des Apache-Webservers 1.3 durch Version 2.0, ein Prozess, der sich auch über mehr als ein Jahr hingezogen hat. Dementsprechend sind auch noch weitere jährliche 3.x Releases geplant, unter anderem um maximal mögliche Stabilität für kommerzielle Produkte auf Eclipse-Basis zu bieten.

JAXenter: Vielen Dank für dieses Gespräch!