Als IBM Ende 2001 den Nachfolger seiner Entwicklungswerkzeuge der Visual-Age-Familie als Open Source freigab, schlug diese Ankündigung in Fachkreisen Wellen. Es ging hierbei schließlich um ein Geschenk, das nach IBM-Angaben dem Wert von 40 Millionen Dollar entsprach. IBM wollte damals laut eigenem Bekunden das für Entwicklungsumgebungen leisten, was die Apache Foundation für Web-Server und Linux für Betriebssysteme geschafft hat. Obwohl die neue Werkzeugplattform versprach, die Popularität der Programmiersprache Java zu erhöhen, fand das Geschenk nicht überall Anklang.

Der Java-Erfinder Sun Microsystems war nicht nur wegen der bezugsvollen Namensgebung des Projekts (Eclipse = Sonnenfinsternis) verärgert, sondern auch, weil die Eclipse-Entwicklungsumgebung in unmittelbarer Konkurrenz zu der von Sun gesponserten Java-IDE Netbeans steht. Die Wellen haben sich in der Zwischenzeit zwar etwas geglättet, aber die beiden Firmen und Produkte konkurrieren weiterhin. Vermutlich deshalb ist Sun bis heute nicht Mitglied der Eclipse-Community. Diese Eclipse-Foundation beruht derzeit auf fünf Säulen: Enterprise-Entwicklung, Embedded Systems, der Rich-Client-Plattform, Anwendungs-Frameworks und natürlich den verschiedenen Entwicklungsumgebungen.

Die Java-Entwicklungsumgebung war der Ausgangspunkt des Projekts und wurde als Version 1.0 Ende 2001 veröffentlicht. Sie war im Kern vollkommen anders konzipiert als die Java-Umgebung von IBMs Vorläufer Visual Age. Dessen Hauptschwäche war das allumfassende monolithische Konzept, das die Integration von Werkzeugen anderer Hersteller nur ungenügend zuließ. IBM stand mit Visual Age permanent unter dem Druck, praktisch alles selbst entwickeln zu müssen. Eclipse brach das geschlossene Visual-Age-Konzept auf und steht eher in der Tradition offener Entwicklungsumgebungen wie IntelliJ Idea, JBuilder und Netbeans. Die genannten Konkurrenzprodukte verfügen ebenfalls über eine offen gelegte Plug-in-Schnittstelle, mit der sich die Entwicklungsumgebungen modular erweitern lassen.

Die ursprüngliche Plug-in-Idee haben die Entwickler so weit perfektioniert, dass die Plattform nur mehr aus einem extrem kleinen Kern und vielen dieser Plug-in-Komponenten besteht. Die Schnittstelle von Eclipse gestattete vielen Fremdherstellern, Plug-ins für Eclipse zu entwickeln und vorhandene Werkzeuge für Eclipse zu portieren. Heute listet die populäre Website "Eclipse Plugin Central" bereits rund 800 kostenlose und kommerzielle Eclipse-Plug-ins auf, während es Netbeans gerade mal auf rund 60 Plug-ins bringt. Aufgrund der Fülle an Erweiterungen kann Eclipse wie kaum eine andere Entwicklungsumgebung individuell an eigene Bedürfnisse angepasst und erweitert werden.

Die Basis: Eclipse-Frameworks

Für die Eclipse-IDE haben ihre Entwickler eine vollkommen neue Oberflächenbibliothek konzipiert. Es kamen also nicht die bekannten GUI-Bibliotheken AWT und Swing des Java-Erfinders Sun zum Einsatz, die Bestandteil der Java-Laufzeitumgebung sind. Der Grund für die Neuentwicklung liegt in den negativen Erfahrungen, die die Eclipse-Entwickler mit dem trägen Verhalten der Swing-Bibliothek und den von ihr verursachten Speicherlöchern machten. Swing garantiert zudem kein wirklich natives Aussehen der mit ihr entwickelten GUIs. Die Eclipse-Entwickler konzipierten das Standard Widget Toolkit (SWT) als Basis und JFace für komplexere Komponenten. Beide Bibliotheken bildeten den Anfang einer langen Reihe neuer Frameworks.

Wichtig für den weiteren Ausbau der Eclipse-Workbench in der Unterstützung für J2EE waren vor allem das Modeling Framework (EMF), das Graphical Editing Framework (GEF) und das Java Eclipse Model (JEM). Diese Bibliotheken bildeten die Grundlage für die Web Tools Platform (WTP), die Werkzeuge für die J2EE-Enterprise-Entwicklung lieferte. Die Eclipse-IDE konnte anfangs gegen die kommerzielle Konkurrenz von Borland und Jetbrains nur teilweise konkurrieren. Das lag an dem für Enterprise-Projekte zu geringen Funktionsumfang der ersten Eclipse-Versionen der Java-IDE. Durch mehrere Projekte hat Eclipse.org mit den kommerziellen Entwicklungsumgebungen nahezu gleichgezogen. Zwei der wichtigsten Projekte dieser Art sind das Visual Editor Project und die Mitte 2004 aus der Taufe gehobene Web Tools Platform.

Das Visual Editor Project wurde Ende 2003 gestartet und stellte Eclipse die Referenzimplementierung des lang ersehnten GUI-Builders zur Verfügung. Durch den Visual Editor ist der Entwickler nun in der Lage, auf visuelle Art und Weise grafische AWT/Swing- und auch SWT/JFace-Oberflächen zu gestalten. Grafische Oberflächen, die mit anderen Werkzeugen wie Netbeans und JBuilder entwickelt wurden, können leicht migriert werden. Das Projekt hat vom Beginn bis zur Version 1.0 nur rund eineinhalb Jahre gedauert. Möglich wurde das durch die tatkräftige Unterstützung der Eclipse-Mitglieder Advanced Systems Concepts, Canoo, IBM, Instantiations und Red Hat. Diese breite Unterstützung durch die Eclipse-Community ist auch für ein anderes wichtiges Eclipse-Projekt typisch, die Web Tool Platform.

Diese neue J2EE-Tool-Plattform besteht aus einer Reihe von Teilprojekten, dem Web Standard Tools Project (WST), dem J2EE Standard Tools Project (JST), dem Ajax Toolkit Framework (ATF), Dali und Java Server Faces (JSF) als Teilprojekt. Das WST liefert Werkzeuge zur Entwicklung von klassischen Web- und Datenbankanwendungen, während das JST Werkzeuge zur Programmierung verteilter Anwendungen zur Verfügung stellt, die einen J2EE-Application-Server zwingend als Laufzeitumgebung benötigen. Ordnung in das Durcheinander der Ajax-Programmierung soll das Ajax Toolkit Framework bringen, während Dali sich dem objektrelationen Mapping widmet. Das Java-Server-Faces-Teilprojekt schließlich stellt Werkzeuge zur Entwicklung von JSF-Web-Anwendungen zur Verfügung.

Die Web Tools Platform sorgte dafür, dass die Eclipse-Workbench mit den Enterprise-Editionen diverser Entwicklungsumgebungen wie IntelliJ Idea, JBuilder und Netbeans sehr gut konkurrieren konnte. Die Auswirkungen dieser Neuentwicklung von J2EE-Werkzeugen für Eclipse waren bei der Konkurrenz enorm. Zum Beispiel verzeichnete Borland, der einstmalige Marktführer im Bereich der Java-Entwicklungsumgebungen, laut eigenen Angaben bei den Verkäufen seines JBuilders im ersten Quartal 2005 so starke Umsatzeinbrüche, dass der Hersteller ankündigte, den JBuilder in seiner bisherigen Form einstellen zu wollen. Mittlerweile hat Borland einen neuen JBuilder auf Eclipse-Basis als JBuilder 2007 vorgestellt. Der traditionelle, auf Swing basierende JBuilder ist tot.

Selbst die kommerziellen Werkzeuge des Eclipse-Initiators IBM haben massive Probleme, sich gegen die immer stärker werdende Open-Source-Konkurrenz Eclipse durchzusetzen. Für die Hersteller kommerzieller Entwicklungsumgebungen gibt es angesichts der schnellen Fortschritte der Eclipse-Entwicklungsumgebung in Bezug auf die J2EE-Programmierung immer weniger Kaufargumente. Die Hersteller konzentrieren sich demzufolge darauf, Marktnischen zu besetzen. Es entstehen luxuriöse Modellierungswerkzeuge auf Basis der Eclipse-IDE, die die bestehenden Lücken und Schwächen der Eclipse-Basis ausgleichen. Beispiele für diesen Trend sind die bekannte Eclipse-Erweiterung Genuitecs MyEclipse sowie auf Eclipse aufbauende Produkte wie Borlands Modellierungswerkzeug Together, Compuwares OptimalJ und IBMs Rational Software Architect (RSA).

Dass die Entwicklungsumgebung von Eclipse inzwischen Marktführer im Java-Bereich ist, wird kaum mehr bestritten. Laut IDC ist die Eclipse-Entwicklergemeinde mit 2,27 Millionen Mitgliedern weltweit die zweitgrößte hinter den Anwendern von Microsofts Visual Studio. Dagegen nimmt sich die Verbreitung der hervorragenden Open-Source-Entwicklungsumgebung Netbeans bescheiden aus. Nach Angaben von Sun arbeiten rund 300 000 aktive Anwender mit dieser Umgebung. Aber die Eclipse-Programmierumgebung steht nicht nur in Konkurrenz zu anderen Java-IDEs, sondern wurde als universelle Entwicklungsumgebung konzipiert. Im Lauf der Zeit sind neben der dominanten Java-IDE verschiedene Ausprägungen der Eclipse-Entwicklung für die unterschiedlichsten Programmiersprachen entstanden: vor allem C/C++, Cobol und PHP.

Das so genannte C/C++ Development Tooling Project (CDT) spielt eine wichtige Rolle bei der Entwicklung von Software für eingebettete Systeme und Mobilgeräte. Zusammen mit der Device Software Development Platform (DSDP), der Embedded Rich Client Platform (eRCP) und den Mobile Tools for Java (MTJ) erleichtern sie dem Entwickler, Software für mobile Geräte sowie eingebettete Systeme zu entwickeln. Nicht die gleiche Popularität konnte das Cobol-Projekt erreichen, um dessen Eclipse-Entwicklungsumgebung es still geworden ist.

Bei der Vielzahl an Plug-ins und der Möglichkeit, mit mehreren Programmiersprachen zu arbeiten, liegt es auf der Hand, dass die Konfiguration einer solchen Entwicklungsumgebung nicht einfach ist. Immer wieder berichten Entwickler in Blogs und Newsgroups über Inkompatibilitäten einzelner Plug-ins und einzelner Eclipse-Projekte mit unterschiedlichen Release-Ständen. Der große Vorteil von Eclipse im Gegensatz zu vorkonfigurierten Umgebungen wie Netbeans hat sich im Lauf der Zeit zu einem ernsten Hindernis für manchen Programmiereinsteiger entwickelt. Dieses Problem hat das Projekt Callisto Mitte 2006 auf den Plan gerufen. Callisto ist ein umfangreiches Vorhaben mit 260 Beteiligten und über sieben Millionen Codezeilen. 15 unabhängige Softwareanbieter und zehn Eclipse-Open-Source-Projekte müssen koordiniert werden. Der Lohn der Arbeit: Unternehmen können mit Callisto eine vorkonfigurierte Eclipse-Umgebung ohne Installationsprobleme übernehmen.

Mitte 2004 erschien gleichzeitig mit Eclipse 3.0 die Rich Client Platform (RCP). Durch sie wurde Eclipse nicht nur als Plattform für Entwicklungswerkzeuge, sondern auch für normale Client- oder Stand-alone-Anwendungen interessanter denn je. Möglich wurde die RCP durch ein Redesign der Eclipse-Plattform. Seit dem Erscheinen von RCP war es nicht mehr notwendig, dass normale Anwendungen werkzeugspezifische Bestandteile von Eclipse verwenden müssen. Zudem wurde die Eclipse-Entwicklungsumgebung stärker auf die Arbeit mit der neuen Client-Plattform ausgerichtet. Laut Umfragen von Evan Data im Jahr 2006 ist die Akzeptanz der RCP im Vergleich zu 2005 um über 120 Prozent gestiegen. Ein bekanntes Beispiel einer Anwendung auf RCP-Basis ist der neue Client der IBM Groupware Notes. Nach Angaben der Eclipse-Foundation gibt es heute 1600 derartige Produkte.

Da der Einsatz der Eclipse-Frameworks auf dem Client und in Rich-Client-Anwendungen auf der Hand lag, konnte lange Zeit niemand die Notwendigkeit erkennen, Eclipse-Frameworks auch zur Server-seitigen Programmierung von Java-Anwendungen einzusetzen. Mit der Rich Server Platform, zu der auch die Rich Ajax Platform gehört, änderte sich dies. Die Rich Ajax Platform ist ein Ajax Framework, das das Programmiermodell der Rich Client Platform auf die Server-seitige Web-Programmierung überträgt. Der Entwickler von Struts- oder Java-Server-Faces-Anwendungen hat also jetzt eine Alternative auf Eclipse-Basis. Dass die Vorstellung eines weiteren Web-Frameworks nicht überall auf Gegenliebe trifft, ist vorprogrammiert. Eclipse befindet sich hier erneut im Konflikt mit den Vorstellungen von Sun Microsystems über die Zukunft von Java.

Eclipse ist aus mehreren Gründen für Entwicklungsabteilungen von Unternehmen interessant. In erster Linie ist die Werkzeugplattform natürlich für viele Anwender gleichbedeutend mit einer kostenlosen, hochwertigen Java-Entwicklungsumgebung. Sie ist nahezu beliebig erweiterbar, vollkommen standardkonform, löst das Problem der Werkzeugintegration und deckt mit verschiedenen Plug-ins den gesamten Lebenszyklus einer Software von der Modellierung über die Konstruktion bis zur Verteilung ab. Durch den hervorragenden Editor und das schnelle Build-System verhilft sie dem Entwickler zu einer Produktivitätssteigerung. Die Flexibilität von Eclipse ist zwar nicht einfach zu beherrschen. Sie ist aber das entscheidende Plus für größere Unternehmen, die meist eine heterogene Software- und Tool-Landschaft betreiben müssen.

Wer verschiedene Softwareprodukte in unterschiedlichen Programmiersprachen und Release-Ständen pflegen muss, weiß, dass er dazu mehrere Entwicklungsumgebungen und einen riesigen Werkzeugkoffer benötigt. In der Vergangenheit war es oft sehr schwierig, die unterschiedlichen Tools unter einen Hut zu bringen. Oftmals gab es Brüche zwischen den Prozessen, an denen verschiedene Tools beteiligt waren. Es kam zu Zeitverzögerungen und Produktivitätsverlusten. Ein nicht unwesentlicher Teil der für die Zusammenstellung einer Entwicklungsumgebung benötigten Zeit ging daher auf das Konto der Werkzeugintegration. Eclipse hilft mit seiner offenen Architektur und der breiten Unterstützung der Plug-in-Hersteller bei der Werkzeugintegration erheblich und trägt dazu bei, unter dem Strich Kosten zu sparen. (ue)