Eclipse 4 - die nächste Generation der freien IDE

24.03.2010 10:29 Uhr Benjamin Muskalla

Nicht nur als IDE, auch als Plattform erfreut sich Eclipse in den letzten Jahren zunehmender Beliebtheit. Mit e4 versucht die Eclipse-Community zurzeit den Weg für die nächste Generation der Applikationsplattform - Eclipse 4 - zu ebnen.

Nicht nur als IDE, auch als Plattform erfreut sich Eclipse in den letzten Jahren zunehmender Beliebtheit. Dass die Rich Client Platform, kurz RCP, initial aus einem Entwicklungswerkzeug entstanden ist, merkt man allerdings heute noch. Mit e4 versucht die Eclipse-Community zurzeit den Weg für die nächste Generation der Applikationsplattform – Eclipse 4 – zu ebnen.

Im Juli 2009 war es soweit – die offizielle Technical Preview von e4 wurde der Öffentlichkeit vorgestellt. Der Codename e4 steht für konzeptionelle und technische Innovation der Technikplattform Eclipse 4. Nach vorangegangenen Ideen und Diskussionen auf diversen Konferenzen hatten die Entwickler einen ersten gemeinsamen Nenner für die nächste Generation der Plattform vorgestellt. Zu beachten ist allerdings, dass es sich bei e4 0.9, so die aktuelle Version, um eine reine Technical Preview handelt. Zwar wird die Community angeregt, erste Migrationsversuche zu unternehmen, das neue Eclipse sollte jedoch nicht produktiv eingesetzt werden.

Die aktuellen e4-Entwicklungen umfassen größtenteils den eigentlichen Runtime-Aspekt von Eclipse, nicht welche Funktionen in der IDE später zu finden sind. Mit der Technical Preview erreichten die Projektbeteiligten das erste Ziel auf dem Weg zur nächsten Version: self-hosting – sprich Eclipse 4.0 mit e4 zu entwickeln. Die Entwickler für die nächste große Version der IDE planen, dass die erste finale Version im Juli 2010 erscheinen wird.

Services – aber in kleinen Dosen

Eines der größten Probleme der heutigen Rich Client Platform ist ihre Komplexität. Durch ihre Historie als Applikationsplattform für die Eclipse-IDE kamen immer mehr APIs hinzu, um RCP als IDE-unabhängige Plattform zu etablieren. Zu konstatieren ist zudem, dass RCP durch seine für den Produktiveinsatz freundliche Lizenz schnell in kommerzielle Produkte einfloss. Das führte unter anderem dazu, dass die APIs bis heute zu pflegen sind, um die Rückwärtskompatibilität zu wahren. Viele Entwickler, die sich in RCP einarbeiten, stoßen früher oder später an einen Punkt, an dem sie nicht sicher sind, welchen Weg sie gehen sollen. Es gibt einfach zu viele Mittel, bestimmte Ziele zu erreichen.

Des Weiteren sind in den letzten Jahren neue Anforderungen aufgetreten, die es umzusetzen gilt, allerdings zur aktuellen Architektur der Plattform im Widerspruch stehen. Das umfasst unter anderem den Einsatz von Eclipse in anderen Anwendungsbereichen wie auf Servern oder Mobilgeräten. Mit Eclipse 4 versucht man, genau den Problemen auf den Grund zu gehen und es zu ermöglichen, Plug-ins und somit RCP-Applikationen mit weit weniger Aufwand zu schreiben. Getreu dem Motto Alan Kays [1]: "Einfache Dinge sollten einfach sein, komplexe Dinge möglich."

Eclipse ist zwar seit Version 3.0, dank OSGi als Komponentenmodell, modular gestaltet. Jedoch sind einige Teile der Plattform bis heute noch relativ monolithisch. Durch den exzessiven Einsatz von OSGi-Bordmitteln soll sich bei Eclipse 4 eine bessere Modularisierung des Eclipse-Kerns erreichen lassen. Die Plattform versucht sich mehr auf ihre eigentlichen Aufgaben zu konzentrieren und erweiterte Funktionen in andere Komponenten (Bundles) auszulagern. Im e4-Kontext spricht man gerne von "the 20 things", also 20 Dingen, die für eine Applikationsplattform am wichtigsten sind. Sie umfassen neben Standardaufgaben wie Fehlerbehandlung und Logging auch altbekannte Konzepte wie den Lebenszyklus von Editoren, lang laufende Operation und zudem Konzepte der Oberflächengestaltung.

Unter dem Motto "Platform as a Service" sollen die Komponenten besser als eigenständige Services miteinander arbeiten, ohne den Preis von Abhängigkeiten zwischen den Komponenten zu zahlen. Konzepte wie Singletons haben die Entwickler komplett aus dem Eclipse-Umfeld verbannt und durch eine neue Strategie ersetzt – den "Context". Er vermittelt zwischen den Verbrauchern und Anbietern unterschiedlicher Services beziehungsweise kann die Services auffinden, auch ohne direkte Abhängigkeiten.

Um die Aufgabe zu lösen und die Abhängigkeiten als Verbraucher solcher Services so gering wie möglich zu halten, wurde das Dependency Injection (DI) Pattern zum Teil der e4-Kernarchitektur. Es erlaubt, dass harte Abhängigkeiten auf bestimmte Teilsysteme nicht nötig sind, sondern sich alle Metadaten und Services über den Context injizieren lassen. Um nicht eine neue DI-Form zu erfinden, zieht man als Grundlage den Java Specification Request (JSR) 330 – "Dependency Injection for Java [2]" – heran, den seit kurzem offiziellen Java-Standard für DI.

Falls man als Verbraucher nicht auf das Pattern angewiesen sein möchte, erlaubt die Context-Architektur, DI auch programmatisch abzufragen. Somit lassen sich je nach Anwendungsfall andere Services an den Consumer herantragen, ohne dass er explizit vom Serviceanbieter abhängt. Das erlaubt eine weitaus höhere Flexibilität der einzelnen Komponenten und fördert die Wiederverwendung der Komponenten in anderen Anwendungsszenarien. Auch erste Schritte Richtung Tooling-Unterstützung für Dependency Injection haben die Entwickler getätigt. Sie sehen viel versprechend aus.

Beim Thema Eventhandling hat sich bei e4 im Gegensatz zu seinem Vorgänger einiges verändert. Bei Eclipse 3.x war es Usus, eine schier unüberschaubare Anzahl an Eventhandlern zu registrieren. Mit e4 wurde ein neuer Event-Bus eingeführt, der über das typische Publish/Subscribe-Muster die Events an interessierte Handler verteilt.

Modeling & Oberflächen

Modellierte Welt

Ein anderes großes Manko der aktuellen Eclipse-3.x-Workbench ist die Komplexität, die auf einen Anwendungsentwickler zukommt, der eine einheitliche Oberfläche erstellen will: Menüs oder Toolbars lassen sich deklarativ anmelden, das Layout einer Perspektive ist zu erstellen, die dazugehörigen Views und Editoren müssen angemeldet werden, ohne über etwaige Interaktionsmittel nachzudenken. Bisher kann das auf vielen unterschiedlichen Wegen geschehen, es ist jedoch nicht möglich, für einfache Zwecke das an einer zentralen Stelle zu tun.

Ein weiteres Manko, das mit der Historie von Eclipse gewachsen ist, ist beispielsweise die strikte Trennung von Views und Editoren. Die Trennung war zu Anfang vielleicht recht sinnvoll, die Grenzen sind in den letzten Jahren jedoch verwischt.

Auch die Wiederverwendung einer UI-Komponente (beispielsweise einer View) in einem Dialog war teilweise nicht sauber realisierbar. Viele Probleme lassen sich mit einem einfachen, jedoch ausdrucksstarken Modell abbilden. Zum Einsatz kam, wie nicht anders zu erwarten, das "hauseigene" Eclipse Modeling Framework (EMF [3]). Die Grundzüge der Anwendung sind somit als Modell umzusetzen, das zur Laufzeit die eigentliche Benutzeroberfläche der Workbench definiert. Durch den abstrahierten Model-Ansatz war es auch ohne größere Hürden möglich, Unterstützungen durch Werkzeuge anzubieten. Der sogenannte "e4 Workbench Designer" erlaubt es einfach, die grundsätzlichen Aspekte der Workbench über einen WYSIWYG-Editor zu erstellen. Zusätzlich stecken die Entwickler zurzeit viel Arbeit in zusätzliche Tool-Unterstützung, um viele der infrastrukturellen Gegebenheiten, beispielsweise Keybindings, zu modellieren.

e4 Workbench Designer (Abb. 1)

(Bild: http://download.eclipse.org/e4/downloads/drops/S-1.0M3-201001142115/e4-news-M3.html)

Beim Designer ist zu beachten, dass es sich nur um die Anordnung von Menüs, Toolbars, Viewparts und deren Gruppierung handelt. Wie der Inhalt der eigentlichen Komponenten zu erzeugen ist, ist freigestellt. Das kann über den klassischen Weg passieren, indem man als Entwickler die SWT- und JFace-Komponenten programmatisch platziert, alternativ aber auch deklarativ, wie man im Folgenden sieht.

Deklarative Oberflächen

Ein gefragtes Thema der letzten Jahre sind Konzepte, Benutzeroberflächen deklarativ zu erstellen. Momentan findet die Entwicklung der UI sowie die Interaktion mit dem Business-Modell noch vollständig in Java statt. Grundsätzlich ist das nicht die schlechteste Art, eine saubere Benutzeroberfläche zu schreiben, jedoch ziehen es viele Entwickler vor, die Arbeit deklarativ anzugehen. Die Vorteile eines solchen Ansatzes wären sowohl die geringere Einstiegshürde als auch der bessere Support für Tools in dem Umfeld. Zusätzlich können deklarative Ansätze eine bessere Abstraktion bieten, um es beispielsweise Domain-Experten zu ermöglichen, aktiv an der Benutzeroberfläche mitzuarbeiten, auch ohne fundierte Java- und SWT-Kenntnisse. Für e4 evaluieren und entwickeln die Projektbeteiligten mehrere Ansätze für das Paradigma. Bisher gibt es jedoch noch keine Deadline, wann sie die Entscheidung für oder gegen eine Technik fällen. Gearbeitet wird momentan an zwei Alternativen:

XWT: Wie das "X" in XWT (XML Windowing Toolkit) vermuten lässt, handelt es sich um eine XML-Beschreibungssprache. Zur Laufzeit liest XWT das XML-Dokument ein und setzt es direkt in konkrete SWT-Widget-Instanzen um. Der Prozess ist also unidirektional. XWT unterstützt den Entwickler nicht nur bei der Komposition der Widgets zu einer ansprechenden Benutzeroberfläche, sondern enthält auch Mittel, die Widgets über Datenbindung an das Domain-Modell zu koppeln. Möchte man auf Data Binding verzichten und auf bestimmte Ereignisse reagieren, bietet es zudem die Option, durch eigene Callbacks auf Ereignisse zu reagieren. Ähnlichkeiten zu XAML (eXtensible Application Markup Language) und XUL (XML User Interface Language) sind zwar vorhanden, jedoch konzentriert sich XWT auf die Eigenheiten von SWT, JFace und des Eclipse Data Binding. Hier ein Beispiel:

<Shell xmlns="http://www.eclipse.org/xwt/presentation"
    xmlns:x="http://www.eclipse.org/xwt">
    <Shell.layout>
       <FillLayout/>
    </Shell.layout>
    <Button text="Hello, world!">
    </Button>
</Shell>

Zusätzlich hat XWT inzwischen einen visuellen Designer, um Oberflächen relativ einfach "zusammenzuklicken". Neben einer Palette mit verfügbaren Widgets ist es möglich aus dem WYSIWYG-Editor heraus, Data-Binding-Beziehungen zu verwalten. Auch erste Schritte hinsichtlich Animationen in SWT wurden durch XWT unternommen. So hat man die Animations-Engine Trident integriert, um einfache Effekte wie Fading direkt über XML zu ermöglichen.

TM: Im Gegensatz zu XWT verfolgt das Toolkit Model (TM) den Ansatz, die Benutzeroberfläche komplett zu modellieren. Vergleichbar mit der Workbench-Idee setzt TM auf EMF und schöpft die Mittel der Modeling-Welt aus. Eine weitere Stärke von TM ist die bidirektionale Verbindung zwischen Widgets und Modell, die erlaubt, zur Laufzeit auf dem Modell zu arbeiten. Änderungen am Modell werden sofort in der UI reflektiert, und umgekehrt. Zusätzlich lassen sich Techniken aus dem Eclipse-Modeling-Umfeld wie CDO (Connected Data Objects) dazu nutzen, das Modell zu persistieren oder sogar über mehrere Applikationsinstanzen zu verteilen.

Deklaratives Styling

Wohl einer der wichtigsten Aspekte aktueller Anwendungen ist ein schickes Aussehen. Zwar ist die Grundidee von SWT, alle Widgets des Betriebssystems zu verwenden und damit ein natives Look & Feel zu erzwingen, jedoch werden die Stimmen für ein besseres Styling von Eclipse-Anwendungen immer lauter. Zugegeben, RCP hat sich äußerlich in den letzten Jahren nicht viel weiterentwickelt. Größere Anpassungen des Look & Feel waren teilweise technisch nur schwer zu erreichen, teilweise sogar unmöglich. Die e4-Entwickler haben deshalb eine Styling Engine entwickelt, die es ermöglicht, SWT Widgets mit CSS (Cascading Style Sheets) in unterschiedlichen Aspekten zu verschönern. CSS war durch seine hohe Akzeptanz im Webumfeld die erste Wahl. Mit der CSS Engine ist es ohne größere Umwege realisierbar, entweder bestimmte Gruppen oder einzelne Widgets nach eigenem Bedarf zu dekorieren. Das ermöglicht es, Entwicklern von RCP-Anwendungen mehr Kontrolle über die Darstellung der Widgets zu geben. Hier ein Beispiel:

Shell, Button, Label { 
    background-color: rgb(48,48,48); 
    color: rgb(240,240,240); 
    font: Verdana 11px; 
}

Button:checked {
     background-color: #FF0000;
}

Auch erweiterte CSS-Konzepte wie Selektoren und Gradienten lassen sich mit der neuen CSS Engine nutzen, um ansprechende Anwendungen zu gestalten.

e4 Contacts Demo mit CSS Styling (Abb. 2)

(Bild: http://download.eclipse.org/e4/downloads/drops/R-0.9-200907291930/e4-news-all.html)

Web to Desktop

Inzwischen verschmelzen die Welten von Desktop- und Webentwicklung immer mehr. In vielen Anwendungsfällen sind Programmierer mittlerweile darauf eingestellt, Funktionen online nutzen zu können. Beispiele wie Online-Banking oder Online-Shops sind nicht mehr wegzudenken. Ein Ziel für Eclipse 4 ist, sich den Anwendungsfällen nicht zu verschließen, sondern sie zum eigenen Vorteil zu nutzen.

Die Idee ist, Komponenten aus dem Web ohne größere Hürden in eigene Applikationen zu integrieren. Als Beispiel wurde ein kompletter Editor mit "handelsüblichen" Webtechniken (HTML, CSS, JavaScript) geschrieben, der eigenständig mit einem Servlet interagiert. Die Webanwendung in Eclipse als eingebauten Editor zu nutzen war eine der Beweggründe für einen solchen Versuch. Während der Editor, wie angesprochen, als reine Webapplikation lauffähig ist, sollte er nicht nur innerhalb einer RCP-Applikation laufen, sondern sich in seine Umgebung integrieren. Beispielsweise war es Ziel, sich in den regulären Lebenszyklus eines Eclipse-Editors einzufädeln – also speichern, wenn man in Eclipse speichert, einen "Dirty Marker" setzen, falls der Benutzer etwas verändert et cetera. Die Entwickler erreichten das, indem sie die Eclipse-API dem eingebetteten Editor als JavaScript-API zur Verfügung stellten. e4 soll die grundlegende API der Workbench auch für andere Sprachen bereitstellen. Nicht nur das Einbetten von anderen Komponenten wird erleichtert, auch die Sprachbarriere soll in Eclipse 4 weitaus geringer ausfallen.

Zudem ist das Einbetten von sogenannten OpenSocial Gadgets in e4 Teil der Plattform geworden. Sie sind wiederverwendbare Webkomponenten, die sich an die Spezifikation von Googles OpenSocial Gadgets API halten. Bekannt sind sie durch Portale wie iGoogle oder auch XING. Hiermit eröffnet sich durch eine einheitliche Schnittstelle die Wiederverwendung existierender Komponenten für sogenannte Mash-ups.

Bisher war der Eclipse-Entwickler darauf angewiesen, alle Plug-ins in Java zu schreiben und zu verbreiten. Um die Limitierung zu überwinden, enthält e4 eine Abstraktionsschicht über OSGi, die erlaubt, Bundles/Plug-ins in anderen Sprachen als Java zu schreiben. Die Aufgabe der Schicht ist, Bundles in anderen Sprachen zu laden, die Abhängigkeiten aufzulösen und für die Sprache eine Laufzeitumgebung bereitzustellen.

Das Beispiel verwendet Rhino, um OSGi Bundles mit JavaScript zu schreiben. Durch die Abstraktion mit Context, Dependency Injection und Event Bus können nun Java- und JavaScript-Bundles miteinander interagieren, ohne zu wissen, in welcher Sprache die Gegenstelle geschrieben ist.

Desktop to Web

Eine andere Richtung, die die Eclipse Rich Ajax Platform (RAP [4]) bisher eingeschlagen hatte, ist, durch "Single Sourcing" bestehende RCP-Applikationen als Webanwendung zur Verfügung zu stellen. RAP erreicht das, indem es SWT durch eine Alternativimplementierung ersetzt, die via HTTP mit einem Webbrowser kommuniziert. Vergleichbar mit der Umsetzung, dass SWT auf diversen Betriebssystemen die nativen Widgets benutzt, verwendet RAP die Architektur, um die Anwendung als JavaScript-Benutzeroberfäche im Browser zu verwenden. Als Anwendungsentwickler merkt man davon wenig, da sich RAP hinter den bekannten SWT-APIs versteckt und Implementierungsdetails somit hinter dieser Fassade versteckt.

Single Sourcing bedeutet, den gleichen Anwendungscode nicht nur für den Desktop-Bereich, sondern auch für die Webapplikation nutzen zu können. Mit RAP lässt sich aus einer Codebasis sowohl einen Desktop- als auch einen Webclient entwickeln. Single Sourcing bewahrt den Entwickler vor dem sonst unvermeidlichen Auseinandergehen redundanter Implementierungen der gleichen Logik. Zudem ermöglicht der Ansatz Java- und Eclipse-Entwicklern, ihr Wissen wiederzuverwenden, indem er ein Java-Programmiermodell unterstützt.

Tatsächlich kommen für Webclients mit RAP die gleichen Werkzeuge und APIs zum Einsatz wie für Rich-Client-Applikationen auf Eclipse-Basis. Das ist sinnvoll, da Ajax eine Desktop-ähnliche Bedienung anstelle des klassischen seitenorientierten Bedienkonzepts erlaubt. Wie sich ein Entwickler von Rich-Client-Anwendungen nicht mit den internen Eigenheiten einer Betriebssystemplattform befassen muss, kommt der RAP-Entwickler nicht mit Webtechniken wie Cookies, JavaScript und dergleichen in Kontakt. RAP ist seit geraumer Zeit eines der Projekte, die die Eclipse Foundation weiterentwickelt und hostet.

RAP ist allerdings nicht direkt Teil der e4-Entwicklung, die Projektmitglieder sind jedoch früh involviert in die Ideen und Entscheidungen, die für e4 getroffen werden. Da viele der für das nächste Eclipse entwickelten Konzepte wie XWT, TM oder der CSS-Support direkt auf SWT basieren, lassen sie sich ohne Weiteres in RAP nutzen. Somit ergeben sich Synergieeffekte, und es ist möglich, e4-Anwendungen ohne Anpassung als Webapplikationen nutzen zu können.

Fazit

Von 3 nach 4?

Viele neue Konzepte beschert e4, doch was ist mit existierenden Plug-ins und RCP-Anwendungen? Sowohl die Anzahl an Plug-ins als auch die kommerzielle Adaption von RCP sind nicht zu verachten bei einer Umstellung dieser Größenordnung. e4 bietet für den Fall eine optionale Kompatibilitätsschicht. Sie ermöglicht, existierende Plug-ins ohne Änderung auf der neuen Eclipse-Plattform benutzen zu können. Das nutzen auch die e4-Entwickler, um beispielsweise die Java Development Tools (JDT) auf e4 benutzen zu können. Eclipse 4 wird also nicht allein "die nächste Version" der Plattform, sondern parallel mit dem 3.x-Entwicklungszweig zur Verfügung gestellt. Das ermöglicht einen reibungslosen Migrationspfad ohne den großen Bruch zwischen beiden Plattformen. Zusätzlich portieren die Entwickler einige Funktionen wie die CSS Engine nach 3.x zurück.

Gute Aussichten

Mit der Technical Preview wurden viele Ideen evaluiert und Erfahrungen für die weitere Entwicklung gesammelt. Es gab viele Ideen, die inzwischen wieder verworfen wurden. Beispielsweise wurde am Anfang von e4 viel Arbeit in die SWT Browser Edition gesteckt. Sie ist jedoch inzwischen aufgrund von Ressourcenengpässen und Alternativen wie RAP wieder verworfen worden. Dagegen ist die Entscheidung für EMF für das Workbench Model sowie für Dependency Injection inzwischen gefällt. Die nächste Eclipse-Generation scheint auf dem richtigen Weg zu sein, Eclipse als Plattform auf neue Wege zu leiten. Wie die Reise weitergeht, sollte nicht nur Aufgabe der aktiven Entwickler sein, sondern mehr denn zuvor die Community bestimmen. Eigene Ideen und Anwendungsfälle in die Diskussionen einzubringen ist der beste Weg, die Plattform zu formen.

Benjamin Muskalla
arbeitet als Softwareentwickler und Consultant bei EclipseSource in Karlsruhe. Er ist einer der Hauptentwickler der Rich Ajax Platform (RAP) und leidenschaftlicher Contributor unterschiedlicher Eclipse-Projekte wie Platform UI und JDT.

Onlineressourcen

Frank Gerhardt, Jochen Hiller, Bernd Kolb; Nachwuchs am Horizont; EclipseCon: das nächste Eclipse wird konkret
e4-Projektseite [5]
e4-Architektur-Whitepaper [6]

(ane [7])

URL dieses Artikels:
https://www.heise.de/-962171

Links in diesem Artikel:
[1] http://de.wikipedia.org/wiki/Alan_Kay
[2] http://jcp.org/en/jsr/detail?id=330
[3] http://www.eclipse.org/modeling/emf/
[4] http://eclipse.org/rap/
[5] http://eclipse.org/e4/
[6] http://eclipse.org/e4/resources/e4-whitepaper.php
[7] mailto:ane@heise.de