Eclipse: Das Schweizer Messer für den Softwareentwickler?

Seit IBM den Quelltext seiner Plattform für Entwicklungsumgebungen als Open-Source veröffentlicht hat, ist einige Zeit vergangen. Kürzlich wurde das Final Release der Version 2.0 freigegeben. Dies soll zum Anlass genommen werden, Eclipse ein wenig genauer unter die Lupe zu nehmen.

Die Plattform

Eclipse alleine ist eigentlich zu fast nichts zu gebrauchen. Es stellt lediglich ein Framework zur Verfügung, das die Entwicklung integrierter Entwicklungsumgebungen ermöglicht. Seine Fähigkeiten bekommt Eclipse durch Plug-Ins verliehen, die je nach Bedarf und Zweck von unterschiedlichen Herstellern integriert werden können.

Für den Entwickler bedeutet dies, dass er, egal ob er in Java, C++ oder einer anderen Sprache arbeitet, die entsprechenden Plug-Ins installiert und eine einheitliche Umgebung vorfindet. Dies gilt im Übrigen auch für die Art des Projektes, mit dem er sich gerade beschäftigt. Benötigt er einen HTML-Editor, ein Tool zum Datenbank-Mapping oder ein UML-Design-Werkzeug, kann er der Entwicklungsumgebung die gewünschte Fähigkeit durch ein Plug-In beibringen.

Eclipse selbst ist in Java implementiert und bringt wohl nicht zuletzt aus diesem Grund in der frei verfügbaren Version alle Werkzeuge (in Form von Plug-Ins) für die Softwareentwicklung in Java mit. Voraussetzung für die Ausführung von Eclipse ist eine installierte Java Laufzeitumgebung (JRE) der Version 1.3. Zur Zeit ist Eclipse für Windows, Linux und andere Unix-Derivate verfügbar.

Die Historie

Mit „VisualAge for Java" war IBM im Bereich der Java-Entwicklungsumgebungen glänzend positioniert. Die besonderen Fähigkeiten, wie das inkrementelle Übersetzen, die Möglichkeit der Codeänderung während der Laufzeit bzw. des Debuggens, die ausgezeichnete Kreuzreferenzsuche und die Team-Komponenten, verhalfen dem Werkzeug zu einer großen Entwicklergemeinde.

Mit der Zeit stellte sich jedoch heraus, dass auch mit der immer Web-zentrierteren Softwareentwicklung einige Nachteile in den Vordergrund rückten. IBM konnte mit der Entwicklung der Java Development Kits (JDK) nicht mehr Schritt halten, da die jeweilige virtuelle Maschine fester Bestandteil der IDE war. Zudem erwies sich das nicht filebasierte Repository zunehmend als Hindernis für die Anbindung externer Tools.

Nachdem die technischen Möglichkeiten nach einigen überarbeiteten Versionen ausgereizt waren, entschied sich IBM zu einer kompletten Neuentwicklung, die im Rahmen der Weiterentwicklung des Applikationservers WebSphere im „WebSphere Studio Application Developer" (WSAD) mündete, welcher auf der ersten Eclipse-Version basiert.

Das Konsortium

Als IBM sich entschloss, Eclipse als Open-Source-Projekt zu veröffentlichen, entschied man sich, dies nicht allein zu tun. Man versuchte, andere namhafte Firmen für ein Konsortium zu gewinnen, um dem Projekt ein entsprechendes Gewicht zu verleihen. Dem Eclipse-Konsortium gehören u. a. Borland, IBM, Merant, Rational Software, RedHat, SuSE, TogetherSoft und WebGain an. Einige dieser Firmen haben bereits ihre Werkzeuge für Eclipse angepasst, andere sind noch dabei, dies zu tun.

Die Federführung im Konsortium hat zur Zeit noch IBM, vertreten durch seine Tochter Object Technology International (OTI), die bis zur Gründung des Konsortiums auch sämtliche Arbeiten zu Eclipse geleistet hatte. In Zukunft soll der Einfluss der einzelnen Mitglieder des Konsortiums durch deren Beiträge zum Projekt bestimmt werden.

Nachdem sich weitere Firmen dem Konsortium angeschlossen haben und auch außerhalb des Konsortiums eine Menge Projekte für Plug-Ins initiiert wurden, scheint sich Eclipse in der Entwicklergemeinde zu etablieren.

Damit wäre auch ein weiteres Ziel erreicht, das IBM nicht ganz uneigennützig mit der Gründung des Konsortiums verfolgte, nämlich die Platzierung eines starken Konkurrenzproduktes zu SUNs NetBeans und Microsofts .NET Werkzeugen.

Die Architektur

Die Eclipse-Plattform stellt zunächst nur einen leeren Rahmen zur Integration verschiedener Werkzeuge zur Verfügung. Dieser Rahmen besteht aus folgenden fünf Komponenten (siehe Abb. 1):

• Platform-Runtime-Modul (PRM)
  Das Platform-Runtime-Modul ist für die Verwaltung der Plug-Ins verantwortlich. Jedes Plug-In verfügt über ein sogenanntes Manifest-File, eine Beschreibung des Plug-Ins und seiner Beziehungen zu anderen Plug-Ins in Form einer XML-Datei. Nach dem Start überprüft das Platform-Runtime-Modul anhand der Manifest-Dateien, welche Plug-Ins vorhanden sind und registriert sie. Der Code des Plug-Ins wird erst dann in den Speicher geladen, wenn es zum ersten Mal angesprochen wird.

  Abb. 1: Architektur der Eclipse-Plattform

• Workspace
  Die verschiedenen Plug-Ins arbeiten auf normalen Dateien, die sich im Workspace des Benutzers befinden. Alle Dateien sind hierarchisch in Projekten organisiert, die mit Verzeichnissen im Dateisystem assoziiert sind. Der Workspace kann mehrere Projekte gleichzeitig beinhalten.
  
• Workbench
  Die Workbench stellt das eigentliche User-Interface, also die grafische Benutzeroberfläche dar. Alle Plug-Ins müssen von den in ihr vorhandenen Komponenten zur Darstellung von Editoren, Formularen, etc. Gebrauch machen.
  Das Standard Widget Toolkit (SWT) stellt dabei eine betriebssystemunabhängige API für die Darstellung einiger grundlegender Komponenten wie Buttons, Menüs, usw. zur Verfügung.
  JFace hingegen baut auf dem SWT auf, und bietet eine API auf einer höheren Abstraktionsebene zur Programmierung von Formularen, Wizards und anderen komplexeren Komponenten. JFace ist unabhängig von dem verwendeten Fenstersystem (Windows, Motif, GTK, …).
  Die Verwendung des SWT (als Alternative zu den Swing-GUI-Komponenten) bringt zwei große Vorteile. Zum einen ist das SWT eine native API, die eine höhere Performance aufweist als die Swing-API, da deren Komponenten für das jeweilige Betriebssystem emuliert werden. Zum anderen sind die Komponenten des SWT optimal an das Look-and-Feel des entsprechenden Betriebssystems angepasst. Dadurch erkennt der Anwender quasi nicht, dass er es mit einer Java-Applikation zu tun hat.
  Ein Nachteil des SWT darf dabei nicht verschwiegen werden: Die Plattformunabhängigkeit geht verloren. Für jede Benutzeroberfläche (Windows, Motif, …) wird eine eigene Implementierung der SWT-API benötigt.
  
• Team-Unterstützung
  Die Team-Unterstützung erweitert die Eclipse-Plattform um ein Versions- und Konfigurationsmanagement (VCM). Dieses kann versionierte Ressourcen (Projekte, Verzeichnisse, Dateien) in verschiedenen, heterogenen Repositories verwalten. Die Unterstützung für das „Concurrent Versions System" (CVS) ist bereits in der Grundversion von Eclipse enthalten.
  
• Hilfesystem
  Das Hilfesystem arbeitet mit einer Kombination aus XML- und HTML-Dateien. Dabei enthalten die XML-Dateien Informationen zur Navigation, während HTML-Dateien die eigentlichen Hilfe-Inhalte zur Verfügung stellen. Die Hilfe-Dateien werden ähnlich den Plug-Ins in der Eclipse-Plattform integriert.

Die frei verfügbare Version von Eclipse bringt von Haus aus die „Java Development Tools" (JDT) als Plug-Ins mit. Damit existiert eine hervorragende, freie Entwicklungsumgebung für die Sprache Java.

Die Konzepte

Die zentralen Begriffe bei der Arbeit mit Eclipse sind „Projekt", „Perspektive", „View" und „Editor".

Ein Projekt strukturiert eine Vielzahl von Dateien und Verzeichnissen. Es können mehrere Projekte gleichberechtigt nebeneinander existieren. Jedes Projekt wird durch einen Typ klassifiziert. Die Klassifizierung ist nicht sprachenabhängig. So kann es zwar Java- und C++-Projekte geben, aber auch Projekte zur Erstellung von Websites mit unterschiedlichen Technologien.

Eclipse bietet die Möglichkeit, jedes Projekt unter verschiedenen Perspektiven zu betrachten. Die möglichen Perspektiven sind abhängig von der Art des Projektes. In einem Java-Projekt kann dies beispielsweise die normale Ansicht zum Erstellen und Bearbeiten der Klassen und Methoden sein (siehe Abb. 2: Normale Ansicht zum Erstellen und bearbeiten der Klassen und Methoden aus der Java-Perspektive.).

Andererseits benötigt der Entwickler beim Debuggen des Projekts völlig andere Informationen. Diese sind in der Debugging-Perspektive (siehe Abb. 3: Debugging-Perspektive.) zusammengefasst.

Die einzelnen „Fenster" einer Perspektive werden als Views bezeichnet. Jede View stellt die Informationen einer Datei in einer oder mehreren für diesen Dateityp spezifischen Weise dar. Für eine HTML-Datei kann dies z. B. die Ansicht als Vorschau oder Quelltext sein.

Analoges gilt für die Editoren, die zur Bearbeitung der verschiedenen Dateitypen existieren. Der
Editor zur Bearbeitung einer Java-Klassendatei bietet z. B. Java-spezifisches Syntax-Highlighting und semantische Auto-Vervollständigung.

Die Features

Die Palette der Fähigkeiten von Eclipse-JDT ist vielfältig. An dieser Stelle sollen nur einige Highlights kurz genannt werden:

• Semantische Auto-Vervollständigung
• Semantische Kreuzreferenzfunktionen
• Inkrementelles Übersetzen
• Hot Code Replace
• (Modifizieren des Codes zur Laufzeit/beim Debugging)
• Unterstützung für beliebige Java Development Kits
• CVS-Unterstützung

Fazit

IBM´s Strategie, Eclipse als Open-Source-Projekt zu fördern, scheint goldrichtig zu sein. Immer mehr Firmen verwenden Eclipse als Basis für ihre eigenen Produkte. Eine kostengünstige Entwicklung effizienter Tools wird so durch das Vorhandensein eines qualitativ hochwertigen Frameworks ermöglicht.

Mit der vorliegenden Eclipse-Version existiert eine sehr gute, freie Entwicklungsumgebung für die Software-Entwicklung in Java. Die kommerziellen Varianten „WebSphere Studio Site Developer" (WSSD) und „WebSphere Studio Application Developer" (WSAD) von IBM sind besonders im Umfeld der Web-Entwicklung schon sehr weit entwickelt.

Der Markt für Entwicklungsumgebungen befindet sich zur Zeit in einer Konsolidierungsphase. Mit WebGain (VisualCafé) hat gerade ein weiterer prominenter Vertreter die Segel gestrichen. Dies ist ein klares Zeichen dafür, dass sich die Geschäftsmodelle, bei denen IDEs zu hohen Preisen vermarktet werden konnten, wahrscheinlich überlebt haben. Durch die kostspielige Entwicklung lassen sich keine ausreichenden Margen mehr erzielen.

Eclipse hat sich mittlerweile einen festen Platz in der Riege der etablierten Entwicklungsumgebungen sichern können. In Zukunft könnte sich bei weiter steigender Akzeptanz der Himmel für JBuilder, NetBeans & Co. tatsächlich verdunkeln.

Seit kurzem bietet ORDIX in Zusammenarbeit mit Object Systems Seminare für Eclipse an. Informieren Sie sich über Inhalte und Termine auf der herausnehmbaren Seminarübersicht in der Mitte dieser ORDIX News. Zusätzliche Informationen finden Sie unter http://training.ordix.de im Internet.

Weitere Informationen zum Thema Eclipse finden Sie im Internet unter www.eclipse.org. Eclipse-Plug-Ins sind unter http://eclipse-plugins.2y.net verfügbar.

Andreas Flügge, Object Systems GmbH (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen