Im Gespräch: Jochen Krause, Geschäftsführer der Innoopract Informationssysteme GmbH

Die Veröffentlichung von Ganymede (Eclipse 3.4) kommt immer näher. Gleichzeitig wird immer wieder von einem Major Release Eclipse 4.0 gesprochen. Jochen Krause und Jeff McAffer haben während des Eclipse Forum Europe zu dem Thema eine Session gehalten und eine kleine Preview auf e4, so der Arbeitstitel für Eclipse 4.0, gegeben.

Eclipse Magazin: Jochen, derzeit steht das so genannte Ganymede-Release vor der Tür, auch Eclipse 3.4 genannt. Zugleich ist immer wieder die Rede von einem Major Release Eclipse 4.0. Welches sind die wesentlichen Ziele dieses Release?

Jochen Krause: Mit Eclipse 4.0 werden wir unseren Fokus auf Innovation setzen: Zum einen wollen wir Eclipse zu einer noch besseren Plattform für Desktop-Applikationen machen. Zum anderen werden wir an der Nutzbarkeit von Eclipse im Browser arbeiten. Das sind die beiden großen Themen. Beiden gemeinsam ist, dass wir für ein viel besseres Styling sorgen müssen.

Als bessere Plattform für Desktop-Applikationen planen wir, drei wesentliche Dinge zu verbessern: Es soll einfacher werden, Plug-ins zu schreiben. Die von der Eclipse-Plattform bereitgestellten Dienste sollen einfacher und einheitlicher werden, und nicht zuletzt werden wir das flexiblere Styling der Benutzerschnittstelle ermöglichen.

Einfachere Plug-in-Entwicklung: Bei der Entwicklung von Plug-ins wollen wir die Nutzung von anderen Programmiersprachen als Java ermöglichen, zu Beginn JavaScript. Einfachere APIs und die Möglichkeit mit Dependency Injection zu arbeiten, sollen die Lernkurve für das Schreiben von Eclipse-Plug-ins deutlich abflachen.
Flexibleres Styling: Wie schon bei Webseiten üblich wollen wir die Gestaltung stärker vom Inhalt trennen, im Moment ist CSS bzw. ein Subset von CSS ein heißer Kandidat für das zukünftige Stylen der Oberflächen.

Einfacheres Eclipse-Applikationsmodell: Die Anzahl der bereitgestellten Dienste soll auf ein übersichtliches Maß begrenzt werden, dazu werden sicher Selection Service, Drag & Drop, Progress, Jobs, Preferences, Logging, Model Listeners und weitere zentrale Dienste gehören. Darüber hinaus wird man eigene Dienste bereitstellen oder auch bestehende Dienste erweitern können.

Dependency Injection zur Bindung der Dienste an die Plug-ins wird die Nutzung flexibler machen. Eine wichtige Neuerung wird die Multi-User-Fähigkeit der Eclipse-Plattform sein. Dies ist auch eine der Voraussetzungen für die Nutzung von Eclipse im Web.

Und damit kommen wir zum zweiten großen Thema: Die Nutzung von Eclipse im Web. Innoopract hat mit RAP hier ja bereits gezeigt, dass dies machbar ist. Mit e4 wollen wir die Möglichkeiten weiter ausbauen und den Entwicklern mehr Flexibilität hinsichtlich Architektur und Implementierung lassen. Neben der serverseitigen Bereitstellung des UI wie bei RAP werden wir ein REST-API anbieten, mit dem man über JavaScript auf beliebige Dienste der Eclipse Workbench zugreifen kann. So kann man Web-UIs ganz nach seinem Geschmack und mit seinen bevorzugten Webtechnologien bauen, ohne auf die bewährte Eclipse-Infrastruktur verzichten zu müssen. Das SWT-Team hat auch noch mit einem weiteren Ansatz experimentiert, nämlich mit Cross-Compiling. Dabei wird der Java-Code der Widgets bzw. der Applikation in ActionScript übersetzt; so laufen mehr Funktionalitäten direkt im Browser. Auch die Übersetzung in JavaScript wie bei GWT ist möglich. Derzeit sind diese Dinge aber noch in einem experimentellen Stadium. Wir gehen davon aus, dass die Nutzung von Eclipse im Web durch eine Kombination aus Eclipse-Technologien auf dem Server und einem Rich UI im Browser erfolgen wird.

Zur Zeitleiste: Für Eclipse 4.0 wollen wir uns ca. zwei Jahre Zeit geben, aber wie es bei uns üblich ist, wird es natürlich auch schon vorher etwas zu sehen und auszuprobieren geben. In einem Jahr wollen wir die wesentlichen Neuerungen implementiert haben und gemeinsam mit der Community evaluieren, ob alles in die gewünschte Richtung läuft. Die Entwicklung des 3.x Stream läuft in der Zwischenzeit unverändert weiter, und das soll auch für die nächsten fünf Jahre so bleiben. Ähnlich wie Apache dies bei der Einführung der Version 2 seines httpd umgesetzt hat, werden wir den 3.x und 4.x Stream eine ganze Weile parallel weiterentwickeln.

EM: Welche Rolle spielt das neu geschaffene Eclipse-Runtime-Projekt (Eclipse RT) bei der Entwicklung von e4?

Krause: Das Runtime-Projekt (Eclipse RT) hat keinen direkten Bezug zu Eclipse 4.0. Einige der Projekte von RT werden in e4 verwendet werden, an vorderster Stelle Equinox, die OSGi-Referenz-Implementierung. Das Runtime-Projekt hat den Fokus, die bei Eclipse seit Längerem implementierten Runtimes zu fördern und auffindbar zu machen. Eclipse wird heute in der Regel als Werkzeug wahrgenommen, und wir wollen zeigen, dass Eclipse auch noch eine andere Seite hat: eine ganze Reihe spannender Runtime-Projekte bei Eclipse wie Equinox (OSGi-Referenzimplementierung), RAP (Ajax), Riena (Smart Client), ECF (Communication), EclipseLink (JPA 2.0/JSR 317-Referenzimplementierung). Eclipse ist schon heute einer der besten Plätze, um OSGi-basierte Implementierungen zu erhalten, in Zukunft werden wir hier sicher noch einiges mehr sehen.

EM: Wie wichtig ist der Aspekt der Abwärtskompatibilität? Wenn Ihr zu viele Altlasten mitschleppt, werden am Ende alle der Meinung sein, dass zu wenig Innovation in e4 steckt - wenn Ihr dagegen die Kompatibilität mit den 3er-Versionen vernachlässigt, dann geht durch die gesamte Eclipse-Gemeinde ein starker Bruch, der ebenfalls nicht zu rechtfertigen wäre ...

Krause: Das Thema hat zwei Seiten: Investitionsschutz und Innovation. Man kann sich darüber streiten, ob diese beiden Dinge überhaupt miteinander vereinbar sind, auf der anderen Seite haben wir schon etwas Erfahrung mit dem Thema und glauben, dass sich beides bis zu einem gewissen Punkt vereinen lässt. Mit dem Release 3.0 wurde bei Eclipse OSGi als neues Komponentenmodell eingeführt und das vorherige, proprietäre Modell abgelöst. Dank eines Kompatibilitätslayers hat das ziemlich gut funktioniert, und die Nutzung von OSGi war eine echte Innovation. Natürlich sind auch einige Plug-ins auf der Strecke geblieben, aber das waren vor allem jene, die sich nicht an die Spezifikationen gehalten hatten.

Wir planen bei e4 im ersten Schritt der Entwicklung keine große Rücksicht auf Abwärtskompatibilität zu nehmen und erst einmal unsere Zielvorstellung der Plattform umzusetzen. Dies beruht natürlich auf den Erfahrungen der letzten Jahre, und wir werden auch codeseitig nicht bei Null anfangen, sondern die vorhandene Core-Infrastruktur definitiv nutzen. Heute sind in der Plattform eine ganze Reihe redundanter APIs vorhanden, die durch die evolutionäre Entwicklung bei gleichzeitiger Erhaltung der Abwärtskompatibilität entstanden sind. In e4 wollen wir damit aufräumen, es wird dann aber zwangsläufig den einen oder anderen Bruch bezüglich Abwärtskompatibilität geben müssen. Aus meiner Sicht ist das vertretbar, wenn die 3er Version der Plattform weiter gepflegt wird und es einen klaren Migrationspfad gibt. Ein Kompatibilitätslayer kann hier auch weiter helfen und wir sind entschlossen, die Investitionen unserer Nutzer keinem unkalkulierbaren Risiko auszusetzen.

RAP wird beispielsweise weiter die 3.x-Version von Eclipse unterstützen, und wer heute ein RCP-Projekt startet, kann sich darauf verlassen, eine leistungsfähige und gewartete Plattform ausgewählt zu haben. Gleichzeitig eröffnet e4 eine interessante Zukunftsperspektive.

EM: Und was hat es mit dem Schlagwort CODA (Component Oriented Development and Assembly) auf sich?

Krause: Wir haben dazu ein Whitepaper geschrieben (www.eclipse.org/equinox-portal/whitepaper/20080310_equinox.php), hier nochmal das Wichtigste in Kürze:

Eclipse Equinox und OSGi vereinfachen den Prozess der Entwicklung und des Deployments moderner Softwaresysteme. CODA bezeichnet den Aufbau von Lösungen auf Basis eines leichtgewichtigen Software-Stacks, der komponentenbasiert erweitert werden kann. Der Equinox Stack ist dabei mehr als nur ein Framework oder eine Ablaufumgebung, sondern bringt bereits funktionsfähige Komponenten für Datenzugriff, SOA, Desktop/Web-UI und weitere serverseitige Funktionalitäten mit. Equinox-basierte Anwendungen sind flexibel einsetzbar, sie können beispielsweise für den Desktop auf allen wichtigen Betriebssystemen angewendet oder auf dem Server einfach in die bestehende Infrastruktur aus Java-Applikationsservern integriert werden.

Equinox und CODA sind ein bewährtes Komponentenmodell, das bei der Entwicklung und Integration von Eclipse-Entwicklungswerkzeugen erfolgreich eingesetzt wird. Die Eclipse-Gemeinschaft erweitert nun die Konzepte und die Technologie, um Equinox in weiteren Anwendungsfällen und auf zusätzlichen Ablaufplattformen einsetzen zu können. Somit erhalten Entwickler ein leistungsfähiges und einheitliches Programmiermodell für Desktops, Server und Devices.

EM: Wie lassen sich überhaupt die verschiedenen wesentlichen Eclipse-Aspekte - Tool-Plattform, Runtime-Technologie für Client und Server - noch in einem einheitlichen Release organisieren?

Krause: Zukünftig werden wir voraussichtlich zwei Releases bei Eclipse haben, eines für die Werkzeuge, ein zweites für die Tools. Das ist noch nicht endgültig entschieden, aber im Eclipse RT PMC (Project Management Committee) gibt es mehrere Befürworter dieser Strategie. Natürlich sollen die beiden Releases dann aufeinander abgestimmt und die passenden Werkzeuge zu den Runtime-Komponenten sein. Und um keine Missverständnisse aufkommen zu lassen: Eclipse wird eine erstklassige Werkzeugplattform für alle möglichen Standards und De-facto-Standards sein, nicht nur für die Eclipse-Runtime-Technologie.

EM: Wer entscheidet schließlich, auf welcher Architektur e4 basieren wird, und wer entscheidet über die enthaltenen Features?

Krause: Wir haben uns bei Eclipse von Anfang an darauf verständigt, dass wir die "Open Source rules of engagement" als Maßstab für unsere Governance etablieren. Ein wichtiges Element dieser Governance ist Meritocracy. Wer sich verdient gemacht hat und viel beiträgt, hat viel Einfluss. Im Plattformbereich bei Eclipse ist das in der Vergangenheit im Wesentlichen IBM gewesen. Für e4 haben sich das Plattform- und das RAP-Team zusammengeschlossen, um gemeinsam eine Kerngruppe für die Entwicklung der nächsten Generation der Plattform zu bilden. Aber dies ist keinesfalls eine geschlossene Gesellschaft, ganz im Gegenteil suchen wir aktiv nach Entwicklern bzw. Unternehmen, die sich ernsthaft an e4 beteiligen wollen. Und mit dem Verdienst kommt dann auch Entscheidungsgewalt. Die Basisarchitektur werden wir in der Gruppe, die e4 implementiert, entscheiden. Ob ein bestimmtes Feature implementiert wird oder nicht, entscheidet letztendlich immer derjenige, der für die Implementierung verantwortlich zeichnet bzw. die Entwicklungskapazität bereitstellt.

Zum Beispiel hatte sich Doug Schaefer vom Eclipse-CDT-Projekt für e4 ein flexibleres Ressourcenmanagement gefordert. Jetzt ist er bzw. sein Team in die Planung von e4 involviert und es sieht so aus, als würden sie die Führung bei der Spezifikation und der Umsetzung übernehmen.

EM: Welche Möglichkeiten zur Mitwirkung hat eigentlich die Community?

Krause: Die Mitwirkung der Community hat bei der Entwicklung der Plattform in der Vergangenheit nur sehr begrenzt stattgefunden. Mit e4 wollen wir dies ändern: Es ist ein wesentliches Ziel von e4, die Mitarbeit an der Plattform einfacher zu machen, gleichzeitig wollen wir transparenter arbeiten als bisher. Eine kleinere, übersichtlichere Codebasis und offene Kommunikation werden die Grundlagen für mehr Community-Beteiligung sein. Zugegebenermaßen gibt es bei uns einiges Lernpotenzial, was die Transparenz bei der Entwicklung angeht. Wir starten mit den besten Vorsätzen und werden uns daran messen lassen. Die Diskussionen über e4 sind schon öffentlich, jeder kann hier mitmachen: eclipse-incubator-e4-dev@eclipse.org. In einem Jahr werden wir beurteilen können, wie erfolgreich wir waren.

EM: Eclipse-Anwendungen sind immer auf den ersten Blick als Eclipse-Anwendungen erkennbar. Inzwischen geht der Trend dahin, dass Generationen von Eclipse-Usern ihre Anwendungen wesentlich stärker "branden", sprich: mit eigenem Design versehen möchten. Was wird e4 in dieser Hinsicht bringen?

Krause: Dieses Problem kenne ich aus erster Hand. Mit unserer Portierung von RCP in den Browser (RAP) haben wir für den veraltet aussehenden Look eine Menge Hiebe bekommen. Im Web war das Styling von Applikationen (Seiten) schon immer viel wichtiger als auf dem Desktop. Heute hat sich dieser Trend auch auf den Desktop übertragen. Insgesamt werden Applikationen viel luftiger konzipiert, die Informationsdichte wird begrenzt. Als Ergebnis erhält man übersichtlichere und einfacher zu bedienende Applikationen, auch wenn dies natürlich nicht immer gelingt.

Es ist kein Problem, mit Eclipse Applikationen in diesem Stil zu erstellen, nur mit dem Styling ist es bisher nicht ganz so einfach. Wir haben bei RAP die Möglichkeit geschaffen, mit CSS Einfluss auf die Gestaltung zu nehmen. Zukünftig wird dies auch für Eclipse-Desktop-Applikationen möglich sein.

EM: Vielen Dank für das Gespräch.

Jochen Krause ist Geschäftsführer der Innoopract Informationssysteme GmbH, einem Anbieter von Software und Dienstleistungen rund um Eclipse. Innoopract ist Hersteller der Eclipse-Distribution Yoxos und von Werkzeugen zur visuellen Webentwicklung (W4T). Jochen Krause repräsentiert Innoopract seit 2003 bei Eclipse und ist Mitglied des Web Tools Project Management Committees (PMC). Er ist Diplom-Wirtschaftsingenieur und beschäftigt sich seit 1992 intensiv mit Informationstechnologien, insbesondere Internettechnologien, objektorientiertem Softwaredesign und Softwareentwicklungsprozessen.