Geniestreich oder Etikettenschwindel?

 
Wird Eclipse 4.0 der nächste große Wurf? Um diese Frage zu beantworten, muss man zunächst einmal wissen, an welchen Technologien im e4-Inkubator-Projekt überhaupt gearbeitet wird, die im Juli 2010 schließlich das neue Eclipse 4.0 SDK ausmachen sollen. Entwickler, die nicht direkt in e4 eingebunden sind, sind nämlich ziemlich ahnungslos diesbezüglich, wie eine Quickvote-Umfrage auf JAXenter.de jüngst gezeigt hat (siehe S. 30 in dieser Ausgabe): Die meisten der Teilnehmer (39 %) entschieden sich bei der Frage: „Was erwarten Sie von Eclipse 4.0“ für die folgende Option:

„Ich kenne die neuen Möglichkeiten von e4 noch nicht genügend, um mir ein Urteil bilden zu können.“

Da fühlen wir vom Eclipse Magazin uns natürlich direkt angesprochen und starten mit dieser Ausgabe eine umfassende Serie zu Eclipse 4.0, in der alle Technologieansätze ausführlich vorgestellt werden.
Als Referenzdokument darf John Arthornes exzellentes e4 White Paper gelten, in dem die sieben Bausteine von e4 kurz beschrieben werden:

• Programming Model: Ein neues, serviceorientiertes Programmiermodell auf Basis von OSGi und Dependency Injection, das eine bessere Isolierung von Softwarekomponenten erlaubt und die Plug-in-Programmierung vereinfacht.
• Flexible Resource Model: Ein neues Ressourcen-Modell soll die Softwareentwicklung mit der Eclipse-IDE flexibler gestalten. Hier sollen u.a. komplexere Projekt-Layouts in Eclipse-Workspaces möglich werden, die z.B. die Kollaboration in verteilten Entwicklerteams besser unterstützen.
• Modeled User Interface: Die Eclipse-Workbench soll in Form eines EMF-Modells bereitgestellt werden.
• Declarative Styling: User Interfaces sollen flexibel über CSS gestaltet werden können.
• Web to Desktop: Ein modular aufgebautes, OSGi-basiertes Framework für JavaScript-Anwendungen soll einerseits Eclipse-Runtime-Technologien in die JavaScript-Welt integrieren, andererseits JavaScript-Anwendungen in der Eclipse-Laufzeitumgebung ausführbar machen. JavaScript soll hier nur den Anfang machen und weitere Sprachen und Frameworks sollen in die Eclipse-Welt integriert werden.
• Desktop to Web: Desktop-Anwendungen sollen ohne großen Aufwand in Webapplikationen verwandelt werden können. e4 soll hierfür zwei Technologien bereitstellen:
  • Ein neuer SWT-Port (SWT Browser Edition, SWT/BE) soll exisitierende SWT-Anwendungen auch auf Webplattformen wie ActionScript/Flash lauffähig machen.
  • Die Eclipse Rich Ajax Platform verfolgt dasselbe Ziel, Anwendungen auf Basis eines uniformen Quellcodes sowohl auf dem Desktop als auch im Web ausführbar zu machen.
• Declarative Widgets: Auch hier gibt es zwei Ansätze:
  • XWT: Declarative widgets in XML: Eclipse 4.0 soll ein XML-User-Interface für SWT enthalten, das das deklarative Entwickeln von Widgets in XML erlaubt. Ziel ist es, die Trennung von Modell und Renderer in alle Bereiche einzuführen, in denen SWT zum Einsatz kommt.
  • TM: Declarative widgets in EMF: Ein konkurrierender Ansatz, dieses Ziel zu erreichen, ist das deklarative Programmieren von Widgets in EMF (Toolkit Model).

 
In dieser Ausgabe nehmen wir uns die ersten beiden Punkte vor: Boris Bokowski beschreibt die Marschrichtung, die im neuen e4-Programmiermodell eingeschlagen wurde (S. 26), Serge Beauchamp erklärt, was es mit dem flexiblen Ressourcenmodell von Eclipse 4.0 auf sich hat (S. 32).
Die Technologieansätze von e4 sind indes nicht unumstritten. Offen ist auch die Frage, ob es sich bei Eclipse 4.0 tatsächlich um eine mit der Einführung von OSGi und Equinox in Eclipse 3.0 vergleichbare Revolutionierung der Eclipse-Plattform handelt oder eher um eine Summe (mehr oder weniger) sinnvoller Ergänzungen (versehen mit dem marketingwirksamen e4-Etikett). Wir werden deshalb neben den technischen Merkmalen von e4 auch die Diskussionen und Kontroversen um e4 in der Community abbilden und neben Committern und Befürwortern auch Kritiker zu Wort kommen lassen. Es konkurrieren hier wohl gewisse Programmierschulen miteinander (man denke an die Frage „Single Source“ vs. „Multiple Source“ bei der Entwicklung von webfähigen Desktop-Applikationen), und manchen geht der mit Eclipse 4.0 vollzogene Kompatibilitätsbruch zur Eclipse 3.x-Schiene zu weit.
„Alles halb so wild“, sagt e4-Project-Lead Mike Wilson und beteuert, dass die meisten 3.x-Plug-ins problemlos auch auf der 4.0-Plattform laufen würden (S. 23). „Innovation ist gut, aber nicht bei der Eclipse-Plattform“, sagt Doug Schaefer und erklärt, warum er sich eine zentrale Architekturinstanz à la Linux auch bei Eclipse wünschen würde (S. 36).

Für Spannung ist also gesorgt. Bilden Sie sich doch einfach selbst eine Meinung!

Hartmut Schlosser
Redakteur