Die Eclipse IDE ist nun bald 20 Jahre alt, für Software- und insbesondere Entwicklungswerkzeuge ein beinahe biblisches Alter. Während es zu damaligen Zeiten nur wenig Alternativen gab und Eclipse den Markt klar dominierte, hat sich das mittlerweile stark verändert. Immer mehr IDEs kämpfen um die Gunst der Entwickler und mittlerweile hat IntelliJ IDEA der Eclipse IDE den Rang abgelaufen. Andere leichtgewichtige IDEs wie VS-Code oder gar Web-basierte IDEs gewinnen immer mehr Nutzer. Eclipse, gerne als alter Dinosaurier verschrien und totgeredet. Nutzer, die Eclipse benutzen, werden bedauert oder verspottet. Steht es denn wirklich so schlecht um die Eclipse IDE? Bei weitem nicht!
Ein Blick zurück
Im Jahr 2012 wurde der Umstieg der Basisplattform von Version 3.x auf 4.x vollzogen. Die damalige Eclipse-Version Juno war tatsächlich eine mittlere Katastrophe. Die IDE war deutlich träger und voller neuer Bugs. Das hat viele Nutzer sehr nachhaltig verärgert. Zum gleichen Zeitpunkt begann der unaufhaltsame Siegeszug von IntelliJ IDEA und ihren Derivaten. Seitdem sind aber bereits sechs Jahre vergangen. Sieben Major-Releases und viele Minor-Releases liegen seitdem dazwischen, in der die Entwicklung nie nachgelassen hat. In der vergangenen Zeit konnte das Team und insbesondere das Eclipse-Platform-Team, das sich für das Basis-Framework verantwortlich zeigt, vergrößert werden. Auch wenn natürlich immer wieder Committer sich anderen Aktivitäten zuwenden und aus dem Projekt ausscheiden oder passiv werden, gelingt es dennoch, immer neue engagierte Entwickler zu finden, die das Projekt weiter vorantreiben. Allein das Eclipse-Platform-Project konnte für die Entwicklung des Photon-Release 117 individuelle Contributoren zählen.
Neuer Release-Zyklus
Mit Eclipse-Photon ist im Juni, pünktlich wie immer, das letzte benannte Simultaneous-Release erschienen. Fortan wird Eclipse vier Mal im Jahr ein sogenanntes Rolling-Release liefern. Das erste, Eclipse 2018-09, wurde im September fertig gestellt und die Version Eclipse 2018-12 wird im Dezember erscheinen. Damit passt sich Eclipse den heutzutage üblichen kürzeren Release-Zyklen an. Dieses Release ist allerdings nicht nur ein Produkt, sondern es nehmen dazu rund 80 weitere Eclipse-Projekte an dem Release-Train teil, die bei Photon etwa 70 Mio. Lines-of-Code ausmachten. Auch auf diese Projekte kommt nun die Herausforderung zu, häufiger mit Releases am Rolling-Release
teilzunehmen. Gerade für das erste Rolling-Release 2018-09 hat das einige Projekte vor Herausforderungen gestellt, so dass auch bis kurz vor Schluss sogenannte Respins erfolgten, die letzte notwendige Updates von Teilprojekten erforderten und integrierten.
Notwendig wurde der kürzere Release-Zyklus u.a. durch die nun aktualisierte Java-Roadmap. Nachdem zwischen Java 1.7, 1.8 und 9 jeweils etwa 3 Jahre lagen, gibt es nun alle 6 Monate ein neues Java-Release. Die entsprechenden Entwicklungswerkzeuge, bei Eclipse ist es das JDT (Java Development Tool), müssen die neuen Spezifikationen natürlich adaptieren und integrieren. Das ist eine ziemliche Mammutaufgabe, doch das JDT-Team leistet hier hervorragende Arbeit und liefert die Eclipse-Unterstützung umgehend. Im Eclipse-Oxygen-Stream passten die Release-Termine für Java 9 und 10 nicht ganz zu den Release-Terminen der Service-Releases, so dass mit Oxygen.1a und Oxygen.3a diese umgehend nachgeliefert wurden. Mit dreimonatigen Releases sind solche Zwischen-Releases nicht mehr notwendig – bis zum nächsten Release ist es nie lang. Die JDT-Unterstützung von Java 11 etwa wurde ein Tag nach dem Java-Release geliefert und kann auf Eclipse 2018-09 installiert werden. In Eclipse 2018-12 wird sie dann direkt integriert sein.
Robustheit durch Eclipse Automated Error Reporting
Mit Eclipse 4.5 wurde das Eclipse Automated Error Reporting eingeführt. Nutzer konnten damit über den Automated Error Reporting Client (AERI genannt) automatisch Berichte an Eclipse schicken, wann immer ein interner Fehler auftrat. Natürlich ist der Nutzer dazu nicht gezwungen, doch genug haben dieses Feature genutzt. Bereits nach einem Jahr wurden so 70.000 Berichte pro Woche gesammelt, Tendenz steigend. Was für den Nutzer mit einem Klick erledigt ist, resultiert für die Entwickler in wertvollen Informationen.
Über diese Fehlerberichte kann festgestellt werden, welche Probleme bei vielen Nutzern häufig auftreten und damit mit höherer Priorität bearbeitet werden. Vieles sind auch “Low-hanging-fruits”: Etwa NullPointerException treten häufig auf, wenn Rückgabewerte von Methodenaufrufen nicht richtig vor der Weiterverarbeitung geprüft werden. Solche Fehler können relativ zügig identifiziert und gelöst werden. Dadurch, dass viele dieser kleinen Fehler nun über Jahre abgearbeitet wurden, konnte Eclipse an sich deutlich robuster gemacht werden.
Was man durchaus auch berücksichtigen sollte ist, dass hinter Eclipse nicht ein großes Unternehmen steckt, sondern vor allem viele kleine sowie enthusiastische Entwickler, die ihren Anteil dazu beitragen, damit dieses komplexe Open-Source-Projekt auch weiterhin erfolgreich vorangetrieben wird und stets kostenlos genutzt werden kann. Es ist damit nicht “die Eclipse-Foundation”, welche die Entwicklung vorantreibt, sondern das Interesse vieler Beteiligter.
Karsten Thoms arbeitet seit über 15 Jahren als IT-Consultant und ist Experte in den Themen Domänenspezifische Sprachen (DSLs), Code-Generatoren, modellgetriebene Entwicklung und Eclipse. Er ist seit vielen Jahren aktiver Eclipse-Committer und gehört zum Kern-Team des Eclipse Xtext Projekts sowie der Eclipse IDE. Seine Kunden berät und unterstützt er bei dem Entwurf, der Entwicklung und Integration von DSLs und ist leidenschaftlicher Open Source Verfechter. Seine Erfahrungen teilt er gerne als Speaker auf internationalen Konferenzen, in Fachartikeln und in seinen Blogs.
