IDE-Wars – Die Foundation schlägt zurück

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!

Java & Eclipse Release-Timeline. (Abb. 1)

Java & Eclipse Release-Timeline. (Abb. 1)

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.

AERI-Problemreport. (Abb. 2)

AERI-Problemreport. (Abb. 2)

Fokus auf Performance
Für Entwickler gibt es nichts Schlimmeres als unnötiges Warten. Dennoch bleibt es nicht aus, dass komplexe Operationen in der Entwicklungsumgebung auch mal Zeit kosten. Gerade hier lohnt es sich auch mal genauer zu untersuchen, ob diese Zeiten nicht verbessert werden können.
Daran haben die Eclipse-Entwickler in der Vergangenheit immer wieder gearbeitet und vor allem für das Photon-Release einige Prozesse in der IDE durch gezieltes Profiling genauer unter die Lupe genommen. Während andere IDEs durch zunehmende Komplexität doch spürbar träger werden, konnte Eclipse an vielen Stellen schneller werden. Vieles mag nicht direkt an einzelnen Aktionen spürbar sein, wie etwa optimiertes Event-Dispatching im Search-View-Trees UI-Framework, doch insgesamt fühlt sich Eclipse reaktiver an als zuvor. An anderen Stellen konnten Operationen, die spürbar viel Zeit verbrauchten, deutlich optimiert werden. So etwa die Expansion des SWT bei großen Treffermengen oder der Importprozess von Projekten aus Git-Repositories.
Performance ist aber nicht nur auf Geschwindigkeit beschränkt – auch die Optimierung der Speichernutzung wirkt sich unmittelbar auf die Geschwindigkeit aus. Weniger Garbage bedeutet weniger Garbage-Collection. Darauf wird in Zeiten moderner Garbage-Collectoren bei der Entwicklung häufig (und oft auch zu Recht) nicht gedacht. Doch eine IDE ist von Natur aus ein anderes Stück Software als etwa ein Microservice. In der IDE werden häufig sehr viele kurzlebige Objekte erzeugt, deren Beseitigung nicht viel, aber doch unnötig Zeit verbrauchen. Gerade bei häufig genutzten Operationen wirkt sich die Vermeidung von Garbage positiv auf die Geschwindigkeit aus.
Eclipse-IDE mit Dark-Theme. (Abb. 3)

Eclipse-IDE mit Dark-Theme. (Abb. 3)

Die dunkle Seite
Heutzutage gelten IDEs mit dunklen Themes als hipp. Mit Einführung der Eclipse-4-Plattform ist ein Theming der IDE möglich und der klassische helle Stil durch ein Dark-Theme austauschbar (Abb. 3). Allerdings war es bislang noch nicht ganz gelungen, dass Theming durchgängig rund zu bekommen. Mit Eclipse Photon hat man noch einmal kräftig daran gearbeitet und nun sieht das Dark-Theme sauber aus. Buttons haben durchgängig dunklen Hintergrund, Icons wurden auch für dunklen Hintergrund optimiert und vieles mehr. Wem das Dark-Theme noch nicht ganz gefällt sollte mal einen Blick auf das DevStyle-Plugin werfen, das über den Eclipse-Marketplace installiert werden kann.
Features, Features, Features
Jedes Eclipse-Release kommt mit einer Hülle neuer Features, die sich hier gar nicht alle aufzählen lassen. Manchmal sind es nur kleine Änderungen, die einen großen Nutzen bringen. So in etwa, dass die Debug-Perspektive überarbeitet wurde und per Default mehr Platz für den zu debuggenden Code lässt. Oder dass im Debugger das Ergebnis des letzten Aufrufs automatisch im Variablen-View angezeigt werden.
Durch die Fülle an Entwicklern mit unterschiedlichem Fokus erhalten mit jedem Release viele nützliche Erweiterungen und Verbesserungen Einzug. Um da halbwegs am Ball zu bleiben sind die umfangreichen New- and Noteworthy Artikel zu empfehlen.
Krieg der IDEs?
Auch wenn es der Titel des Artikels ein wenig provoziert, einen echten Krieg der IDEs gibt es nicht. Es ist Geschmackssache und abhängig von Unternehmen und Projekten, welche IDE vorteilhaft ist oder halt einfach vorgegeben wird. Aussterben wird die Eclipse IDE jedenfalls noch viele Jahre nicht. Durch die aktive Entwicklung wird sie ständig an die neuen Bedürfnisse der Anwender angepasst. Nicht ändern wird sich, dass es eine Desktop-Anwendung ist und der Bedarf nach anderweitigen Entwicklungswerkzeugen durchaus vorhanden und berechtigt ist. Alle diese Werkzeuge werden ihren Anteil am Markt haben. Davon wird Eclipse nicht den größten Teil haben, aber weiter einen signifikanten.

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.

Fazit
Die Eclipse IDE ist aus dem Markt der Entwicklungswerkzeuge nicht wegzudenken. Die Entwicklung ist sehr aktiv und wird durch einen neuen dreimonatigen Release-Zyklus noch einmal beschleunigt. Die neuesten Java-Standards werden jeweils unmittelbar unterstützt und gleichzeitig wird an vielen hilfreichen Features gearbeitet. Mit dem Eclipse Photon-Release konnte noch einmal ein deutlicher Sprung nach vorn in den Bereichen Performance, Speichernutzung, Robustheit und Usability gemacht werden. An diesen Bereichen wird auch in Zukunft besonders intensiv gearbeitet. Die Eclipse IDE bleibt ein wichtiges und nützliches Werkzeug für die Entwicklung von Projekten aller Art.


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.

Carolyn Molski


Leave a Reply