Mehr als eine Entwicklungs- umgebung

Obwohl Eclipse ursprünglich als Basis-Applikation für verschiedenste Entwicklungstools konzipiert und ent-wickelt wurde, stellt sie eigentlich eine Plattform für irgendwelche Rich-Client-Applikationen dar. Mit der Rich Client Platform (RCP) von Eclipse und den darin verwendeten Widget-Toolkits SWT und JFace steht dem Entwickler eine durchdachte, modulare und leistungsfähige Grundarchitektur für eigene Applikationen zur Verfügung. Mit dem neuesten Release 3.1 von Eclipse wird RCP noch stärker in den Vordergrund gerückt.

Die Eclipse-Plattform weist eine sehr stark komponentenorientierte Architektur auf. Sämtliche Funktionalität wird in sogenannten Plug-ins implementiert. Darunter liegt ein relativ kleiner Kernel, die Platform Runtime Engine (Grafik). Diese ist dafür verantwortlich, Plug-ins beim Applikationsstart zu detektieren, registrieren, deren Abhängigkeiten aufzulösen sowie den Plug-in-Lebenszyklus zu steuern.

Ein Plug-in besteht aus Java-Code in einem jar-File, Ressourcen wie Bilder, Icons, Templates, Text-Kataloge, Native-Code-Libraries sowie einer XML-Beschreibung plugin.xml. Plug-ins werden untereinander durch im plugin.xml deklarierte Verbindungspunkte, Extension Points, verknüpft. Ein Plug-in kann Extension Points anderen Plug-ins zur Verfügung stellen, so quasi als öffentliches API. Ebenso kann es Extension Points anderer Plug-ins verwenden. Zusammen mit Infrastruktur-Klassen und -Interfaces wie Adaptoren kann eine klar definierte und erweiterbare Verbindung hergestellt werden, welche auch unterschiedliche Release-Zyklen einzelner Plug-ins erlaubt.

Funktionale Extension Points, welche eine Verbindung mit dem User-Interface aufweisen, deklarieren im plugin.xml bereits schon Text-Labels oder Icons. Dies erlaubt es, in einem Menü oder in einer Toolbar die Funktion anzubieten, ohne dass dazu das implementierende Plug-in bereits geladen und aktiviert werden muss. Der Lade- und Aktivierungsmechanismus kommt erst dann zum Zuge, wenn die Funktion auch tatsächlich ausgeführt wird. Diese wirkt sich sehr positiv auf die Performance und den Ressourcenverbrauch aus.

Einfachste Applikationen können ihre gesamte Funktionalität in ein einziges Plug-in packen, komplexere werden pro funktionale Einheit ein Plug-in erstellen. Eclipse mit den Java Development Tools selber besteht beispielsweise aus über 80 Plug-ins.

Ebenso zum Konzept von Eclipse gehört der Workspace und die Workbench. Der Workspace - physikalisch in einem Verzeichnis-Baum der Harddisk angesiedelt - stellt einen Datenspeicherbereich für die Plug-ins zur Verfügung. Jedes Plug-in kann dort Daten persistent ablegen. Die Workbench schliesslich definiert die Grundgestalt des Hauptfensters der Applikation. Eclipse unterscheidet hier zwischen Views und Editoren. Editoren folgen dem Open-save-close-Lebenszyklus eines Dokumentes beziehungsweise eines allgemeinen Datensatzes, Views hingegen dienen oft zur Anzeige von kontext- oder selektionsabhängigen Zusatzdaten. Layouts von Views und Editoren können in sogenannten Perspektiven zusammengefasst werden. Mit einem Perspektivenwechsel kann somit der Benutzer der RCP-Applikation einfach und schnell zwischen aufgabenspezifischen Ansichten wechseln.

Für die Erstellung der Benutzerschnittstelle basiert Eclipse RCP auf den beiden Frameworks SWT (Standard Widget Toolkit) und JFace - ein Gespann, welches sich mit den Widget-Frameworks AWT und Swing vergleichen lässt. SWT bietet ein Betriebssystem-unabhängiges API für Benutzerschnittstellenelemente (sogenannte Widgets). Dieses API ist recht «leicht» und setzt direkt auf dem Windowing-System des Gastrechners auf. Im Gegensatz zu AWT beschränkt es sich dabei nicht nur auf dem gemeinsamen Nenner aller unterstützten Betriebssystem-Plattformen, sondern bietet ein Common-API für die «üblichen» Widgets. Nach Möglichkeit wird dafür direkt auf den Native-Widgets aufgesetzt, ansonsten werden diese emuliert. Zusätzlich sind aber auch Funktionen, welche für eine spezifische Plattform besonders wichtig sind, über SWT zugänglich. Unter Windows ist das etwa die ActiveX-Integration. Die Verwendung solcher Funktionen ist dann natürlich nicht mehr portabel.

JFace baut auf SWT auf und bietet ein UI-Toolkit mit Klassen für übliche UI-Programmieraufgaben. Ähnlich wie Swing basiert JFace auf einem Model-View-Konzept, bei welchem ein abstraktes Datenmodell die Inhalte für die View-Komponenten (in JFace: Viewers) wie Tabellen, Trees, Listen und Eingabefelder liefert. Aber auch Dinge wie Benutzer-Dialoge, Preferences, Wizards, Actions oder Progress-Dialoge stehen dort im Repertoire.

Während Swing per Default auf ein plattformneutrales und -übergreifendes «Look & Feel» setzt und das als Vorteil herausstreicht, geht SWT/JFace bewusst einen anderen Weg: Das Look & Feel ist dasjenige der Plattform, auf welcher die Applikation läuft. SWT-Anhänger betonen dann auch, dass dadurch sich eine SWT-Applikation wie native anfühlt, während Swing, auch wenn als «Skin» das «Native Look&Feel» gewählt wird, oft seine Java-Basis nicht verheimlichen kann. Der Kampf von Swing, um subtile Abweichungen der emulierten Benutzeroberfläche vom Original auszubügeln, wird dort auch in Zukunft noch viel Energie verschlingen. Swing-Applikationen gelten gerade auch wegen den Emulationsschritten, trotz starken Verbesserungen in den letzten Jahren, als weniger performant als solche basierend auf SWT.

Für den Entwickler ist ein Wechsel oder sogar ein Hin- und Herspringen zwischen SWT/JFace und AWT/Swing relativ einfach, da die Konzepte auf API-Level nicht fundamental anders sind.

Wie beim Einsatz von anderen Frameworks gilt auch hier: Der Profit von Eclipse-RCP ist dort am höchsten, wo das Applikationsdesign und die Implementation nahe an den Prinzipien des Frameworks liegen. Abweichungen davon finden nicht nur keine Unterstützung durch das Framework, sondern führen oft zu konzeptionellen Inkompatibilitäten. Steht eine Entwicklerin vor einem Problem, dann findet sie am besten die Lösung, indem sie bei anderen nachschaut, wie es dort gelöst wurde. Dadurch, dass der Quellcode der gesamten Eclipse-Java-IDE (und auch der anderen Eclipse-Projekte) frei verfügbar ist, sich mit Eclipse bequem «besurfen» lässt und gleichzeitig dieser Code auch in einer lauffähigen Version zur Verfügung steht, ist dies ein besonders attraktiver Weg. Das durchdachte und kohärente Design des Basis-Frameworks und der Java-Development-Tools-Plug-ins machen Spass und laden ein, für die eigene Applikation die Design-Patterns zu übernehmen. Der Lerneffekt dabei ist gross.

Funktionalitäten wie ein Online-Help-System oder ein Update-Manager können auch ohne eigenen Code direkt als Plug-in in die eigene Applikation übernommen werden.

Die Eclipse-Plattform hat sowohl als Träger von einer Vielzahl von Tools für Software-Entwickler wie auch als allgemeine Applikations-Plattform sehr viel Drive, Coolness und Ansehen. Schon die eindrückliche Liste von potenten Firmen und Sponsoren, welche hinter Eclipse stehen und viel in die Plattform investieren zeigt, dass Eclipse-RCP nicht ein Strohfeuer darstellt, welches bald wieder vom Markt verschwinden könnte.

Gerade auch die neueste Version 3.1 von Eclipse mit stark verbesserter Unterstützung des RCP-Entwicklungsprozesses zeigt, dass RCP neben der bekannten Java-IDE ein starkes Standbein werden soll. Die Liste der kommerziellen und freien Software, welche darauf basieren und die täglich wächst, zeigt das grosse Momentum.

Eclipsehttp://www.eclipse.org/rcp/: Eclipse-RCP-Homepage, mit viel Dokumentation, Tutorials und weiterführenden Links.Erich Gamma, Kent Beck; «Contributing to Eclipse»; ISBN 0-321-20575-8: Hervorragende Lektüre nicht direkt zu RCP-Entwicklung, sondern mehr zu Konzepten hinter Eclipse, dem richtigen Design von Eclipse-Plug-ins, den verwendeten Design-Patterns und moderner Software-Entwicklung.Rob Warner; «The Definitive Guide to SWT and JFace»; ISBN 1-59059-325-1: Nachschlagewerk für Fälle, wo das Lesen von Online-Dokumentation zu anstrengend ist.

Der Autor:
Joachim Hagger ist Chief Technology Officer (CTO) und Partner bei der Zürcher Softwarefirma Netcetera.