Tom Schindl hat am 14. Januar an einer Präsentation in Zürich mit e4 die nächste Generation der Eclipse Plattform vorgestellt und die wichtigsten Neuerungen erklärt.

Letzten Freitag 14. Januar hatte ich das Vergnügen, in Zürich eine Präsentation von Tom Schindl über e4 zu sehen. Tom ist in der Eclipse Welt kein Unbekannter, er ist als Committer in etlichen Eclipse Projekten (Jface, nebula etc.) tätig und einer der Urheber von e4. In dieser Präsentation hat er die nächste Generation der Eclipse Platform vorgestellt und die wichtigsten Neuerungen und Design-Entscheidungen erklärt.

e4 ist keine Weiterentwicklung von Eclipse 3.x. Es werden zwar verschiedene existierende Komponenten und Technologien verwendet, die eigentliche Applikation jedoch ist eine komplette Neuentwicklung. Die erste Version von e4 soll voraussichtlich im August 2010 erscheinen. Daneben wird aber auch Eclipse 3.x weitergepflegt (laut Tom noch weitere 5 Jahre). Somit ist die Zukunft von auf Eclipse RCP 3.x basierenden Produkten gesichert. Für Neuentwicklungen lohnt es sich aber, als Basis e4 in Betracht zu ziehen.

Ich gebe hier einen Überblick über die von Tom vorgestellten Neuerungen in e4 gegenüber der aktuellen Eclipse 3.x Linie und gehe dabei auch auf technische Aspekte ein. Der Artikel wendet sich vor allem an Entwickler, welche bereits die aktuelle Eclipse 3.x Platform für RCP Projekte verwendet haben.

Warum e4?

Es gibt mittlerweile einigen Legacy Code in der 3.x Platform und es ist schwierig und aufwändig geworden, ihn zu verstehen und zu warten. Ein Grund hierfür sind beispielsweise die vielen verschiedenen und inkonsistent verwendeten MVC Implementationen und Event Modelle. Dazu kommt, dass in der 3.x Linie die Altlasten nicht radikal aufgeräumt werden können, um die Kompatibilität zu bestehenden Eclipse Plugins und RCP Applikationen nicht zu gefährden.

In Eclipse 3.x wurden alte Patterns verwendet, die eine Weiterentwicklung stark einschränken. So erschweren Singletons und Statics das Realisieren von Mehranwenderapplikationen. Weiter ist die tiefe Verschachtelung und Vererbung der Komponenten problematisch. Eine Komponente in 3.x ist häufig so stark spezialisiert, dass sie nur an ganz wenigen Stellen wiederverwendet werden kann. So kann zum Beispiel ein EditorPart nie in einem Dialog, sondern nur in der Editor Area verwendet werden.

Eclipse RCP war lange sehr erfolgreich als Applikationsplatform. Es gibt aber inzwischen Konkurrenz und neue Trends: Dank dem Web 2.0 mit all seinen interaktiven Möglichkeiten werden Applikationen vermehrt als Webapplikation realisiert. Auch auf dem Desktop sind neue UI Philosophien aufgetaucht mit einer klaren Tendenz zu mehr “Flash like” Aussehen statt nativem Look. Eclipse muss sich diesen Anforderungen anpassen um erfolgreich zu bleiben.

Das e4 Programming Model

In e4 existieren keine Singletons. Komponenten sollen benutzte Referenzen nicht selber holen und dadurch an ein starres API gebunden sein. Stattdessen werden alle benötigten Referenzen per Dependency Injection geliefert, was tiefe Vererbungshierarchien, wie sie bei Eclipse 3.x vorkommen, verhindert. In e4 sind alle Building Blocks (Komponenten) POJOs, die keine Interfaces realisieren müssen. Dazu implementiert e4 den Java Standard JSR 330 für Dependency Injection mit ein paar eigenen Erweiterungen.

e4 definiert ein Standardset von Services, welche Komponenten verwenden können. Die Services sind als OSGi Declarative Services implementiert und werden per DI in die Komponenten injiziert. e4 bietet also eine zentrale Stelle mit einem einheitlichen Interface, um Services zu benutzen.

Modellierte Workbench

In Eclipse 3.x gibt es für die unterschiedlichen Komponenten unzählige Registries. In e4 sind alle Komponenten POJOs und an einer einzigen zentralen Stelle, dem Workbench Model, registriert.

Statt selbst eine proprietäre Model-Technologie für das Workbench Model zu entwickeln, kommt EMF zum Einsatz. Somit können etliche ausgereifte EMF Komponenten direkt und ohne zusätzlichen Entwicklungsaufwand verwendet werden: ein elementarer Model Editor, EMF Compare um verschiedenene Workbench Models zu vergleichen, CDO um Workbench Models übers Netz zu verteilen, etc.

Mit dem Basis-Metamodel von e4 wird das UI der Applikation mit Fenstern, Menus, Perspektiven bis hinunter zu den Parts (View/Editor) deklarativ modelliert. Das UI der Parts kann auf herkömliche Weise implementiert werden, zum Beispiel mit SWT oder mit JFace Forms.

Das Basis-Metamodel lässt sich aber auch beliebig erweitern, so kann bei Bedarf das Modellieren der UIs von Parts ermöglicht werden.

UI Rendering und Styling

In e4 sind das Applikationsmodel und das UI strikt getrennt. Die e4 Applikationsplatform selbst ist Widget/Toolkit agnostisch, das UI wird anhand des Models von einer Presentation-Engine gerendert. Die Standard-Presentation-Engine von e4 rendert das UI, wie von Eclipse gewohnt, mit SWT. Es können aber eigene Presentation-Engines geschrieben werden, welche ein anderes Toolkit verwenden.

Die Presentation-Engine verwendet für jedes UI Element einen spezifischen Renderer. Dieser lässt sich durch eine andere Implementation austauschen, wenn ein Element verschieden gerendert werden soll. Für ein Element können auch mehrere Renderer vorhanden sein. Die Presentation-Engine entscheidet dann anhand von definierbaren Kriterien, welcher Renderer im Einzelfall verwendet wird.

Die Applikationslogik ist also für verschiedene Platformen wiederverwendbar (Desktop, Web, Mobile, etc.). Je nach Platform lässt sich dabei eine angepasste Presentation-Engine einsetzen, so dass das UI immer optimal dargestellt wird.

Weiter ermöglich diese klare Separation von Applikationsmodel und UI Rendering, dass der Code mit der Applikationslogik testbar ist, ohne dass ein Toolkit und ein UI instanziert werden müssen.

Das Aussehen von SWT Widgets (Farbe, Font, Ausrichtung…) ist neu über CSS Stylesheets definierbar. So lässt sich das Aussehen der Applikation ohne Anpassung des Codes alleine durch die Modifikation oder den Austausch eines Stylesheets verändern. Dies funktioniert sogar zur Laufzeit der Applikation.

Hauptziele von e4

Vereinfachte Entwicklung von UI Komponenten:

• Programming Model mit Dependency Injection
• eindeutig definierte Applikations Services
• deklaratives UI

Vereinfachte Entwicklung/Anpassung von auf e4 basierenden Applikationen:

• modellierte Workbench
• Presentation-Engine und Renderer
• Styling von SWT Widgets mit CSS Stylesheets

Tom hat uns an dieser Präsentation einen interessanten Einblick in die Entwicklungsrichtung von e4 gegeben. Die kommende Generation von Eclipse verspricht viele neue, spannende Möglichkeiten.
Die Vortragsslides von Tom finden Sie hier.