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.
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.
7. November 2001: IBM veröffentlicht den Sourcecode von Eclipse;
29. November 2001: Gründung des Eclipse-Konsortiums;
18. September 2002: Eclipse 2.0;
17. November 2003 :Visual-Editor-Projektstart;
8. Dezember 2003: Visual Editor 0.5;
2. Februar 2004: Eclipse.org wird Non-Profit-Organisation;
21. Juni 2004: Eclipse 3.0;
26. Juli 2004: Start für das Projekt "Web Tools Platform";
27. Juni 2005: Eclipse-Foundation hat 100 Mitglieder;
29. Juni 2005: Visual Editor 1.0.2.2;
19. Dezember 2005: Web Tools Platform 1.0;
21. März 2006: PHP-IDE-Projekt angekündigt;
26. Juni 2006: Startschuss für Callisto;
28. Juni 2006: Visual Editor 1.2;
8. Februar 2007: Web Tools Platform 1.5.
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).
Die beiden GUI-Bibliotheken SWT/JFace verfügen über einige Reihe von Vorteilen wie zum Beispiel, dass die Oberflächenbausteine überwiegend vom Betriebssystem gezeichnet werden. Sie sehen daher hundertprozentig so aus wie es der Anwender gewohnt ist und verhalten sich auch so. Im Gegensatz zu AWT/Swing müssen sie allerdings für jedes Betriebssystem portiert werden und befinden sich nicht im Standard der Java-Laufzeitumgebung (JRE). Daher ist die Auslieferung von Programmen, die SWT/JFace oder die darauf aufbauende Rich Client Platform (RCP) verwenden, nicht ganz so einfach wie bei Produkten, die die Standard-GUI-Bibliotheken AWT/Swing einsetzen. Ein Teil der Portabilität eines Java-Programms geht mit SWT/JFace verloren.
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.
