Was sich in der Eclipse IDE getan hat

Eclipse 2019-12: Das beste Eclipse-Release aller Zeiten?

Lars Vogel, Jennifer Nerlich

© Andrei YUL/Shutterstock.com

Wenn Sie diesen Artikel lesen, ist das Eclipse-2019-12-Release aktiv freigeben und das Release 2020-03 wird fleißig entwickelt. Inzwischen ist das Eclipse-Projekt so aktiv, dass wir in den dreimonatlichen Releases genauso viel Funktionalität finden, wie früher in einem Jahresrelease. Das nehmen wir zum Anlass, zu schauen, was sich in den letzten Releases und im Prozess getan hat.

Möglicherweise handelt es sich bei 2019-12 um das beste Eclipse-Release aller Zeiten und es scheint auch so, als ob Eclipse wieder die Markführerschaft im Bereich der Java IDEs zurückgewinnt. Schauen wir also mal, wieso die Benutzer zur Eclipse IDE zurückkehren bzw. was treue Eclipse-Nutzer im aktuellen und im zukünftigen Release so erwartet.

Vier Millionen Downloads des 2019-12 Eclipse-Release

Während mit Eclipse 4.2 und den folgenden Releases die Benutzerzahlen der Eclipse IDE sanken, hat sich dieser Trend inzwischen umgedreht. So wurde das Eclipse-2019-09-Release mehr als vier Millionen (!) Mal heruntergeladen, und in diesen Zahlen sind noch nicht die Updates von Benutzern älterer Releases enthalten. Alles in allem eine beachtliche Benutzerzahl in einem überladenen und heißumkämpften Markt.

Tatsächlich war in den letzten drei Jahren jedes Eclipse-Release besser als das letzte. Während andere IDEs inzwischen tendenziell recht träge reagieren, zahlt sich der Fokus der Eclipse-Entwickler auf Performance aus. IDE-Benutzer mögen eben gerne schnelle Tools und hier ist die Eclipse IDE inzwischen sehr gut aufgestellt.

Klimawandel zum Besseren

Nicht zu unterschätzen ist die Projektkultur eines echten Open-Source-Projekts (OS). Bei proprietärer Software bzw. bei OS-Projekten, an denen primär ein Unternehmen arbeitet (unternehmensgetriebenes OS), werden die Entwickler bezahlt, um etwas umzusetzen.

Dagegen muss ein Open-Source-Projekt, das von vielen Unternehmen und Individuen weiterentwickelt wird, auf eine gesunde Projektkultur achten.

Auch hier ist in den letzten Jahren viel passiert. Vor einiger Zeit wurde im Projekt noch aktiv das Blaming einiger Projektmitglieder betrieben. Wenn jemandem ein Fehler passierte, wurde auf diese Person beispielsweise ordentlich verbal eingedroschen, mit Sätzen wie „How could you not see?“, „You made this mistake again“ oder „Your errors are wasting my time“ und vieles mehr. Auch wurden Patches, die die Codequalität oder Lesbarkeit verbessern, gerne als „useless cleanup patches“ oder „waste of time“ bezeichnet.

Dieses Verhalten hat der Eclipse-Entwickler-Community sehr geschadet. Viele Committer und Contributors kehrten dem Projekt den Rücken, da man sich ungern beleidigen lässt. Insbesondere wenn man in seiner Freizeit etwas zum Code beiträgt.

Zum Glück ist dieses Verhalten inzwischen weitgehend unüblich bzw. passen die aktuellen Projektmitglieder auf, dass solche verbalen Ausrutscher schnell korrigiert werden. Auch hat das Leitungskomitee des Eclipse-Projekts festgelegt, dass Patches, die die Codequalität verbessern, definitiv gewünscht sind. Damit wurden die häufig endlos wirkenden und für die betroffenen Entwickler entmutigenden Diskussionen über „useless cleanup patches“ endgültig beendet.

Viele Codechecks, die früher manuell durchgeführt werden mussten, wie z. B. die sogenannten API-Baseline-Checks, sind inzwischen Teil der Gerrit Build Verification für die Patches, Fehler werden damit automatisch entdeckt und führen damit nicht mehr zu Blame-E-Mails.

Als Ergebnis arbeiten die Entwickler inzwischen offener, trauen sich mehr und Fehler werden (meist) auf konstruktive Art und Weise gefixt. Diese Fehlertoleranz führt dazu, dass mehr alte und neue Baustellen angegangen werden und die Benutzer damit auch immer mehr Funktionalität und schnelleren Code bekommen.

Bewegung in den Bugs

Ebenfalls werden Patches oder Bugs in den meisten Fällen nicht mehr monate- oder jahrelang ignoriert. Inzwischen bearbeiten viele Committer und Contributors neue und alte Bugs und liefern schnell Antworten oder Fixes. So hat sich beispielsweise die Antwortzeit bei neuen Bugs in der Eclipse-Platform-UI-Komponente von durchschnittlich zehn Tagen vor drei Jahren auf aktuell drei Tage verkürzt.

Im Rahmen eines Forschungsprojekts namens OpenReq haben die Autoren dieses Artikels u. a. analysiert, wie sie die horrende Anzahl offener Eclipse-Bugs reduzieren und besser visualisieren können. Ziel dieses Projekts war für die vogella GmbH, eine intelligente, personalisierte Darstellung von Bugzilla-Einträgen direkt in der Eclipse IDE zur Verfügung zu stellen. Der erfahrene Leser kann sich das wie eine Mischung aus Mylyn und Code-Recommenders vorstellen. Diese Darstellung sollte eine so gute Priorisierung auf Basis persönlicher Präferenzen des Users und Relevanz des Bugs für das Eclipse-Projekt liefern, dass der User, der nach einem Bug zum Contributen sucht, schnell einen findet (Abb. 1).

Abb. 1: Der Bug-Prioritizer

Das OpenReq-Eclipse-Plug-in wird bereits bei einigen Eclipse Key Players verwendet und das Feedback war immer sehr positiv. Falls Sie in Zukunft auch schnell einen passenden Eclipse-Bug finden wollen, können wir dieses Plug-in von ganzem Herzen empfehlen. Es kann über den Eclipse Marketplace über den Suchbegriff „openreq“ gefunden und installiert werden.

Je schneller die Suche nach einem Bug abgeschlossen wird, desto mehr Bugs können bearbeitet und geschlossen werden und desto glücklicher ist die gesamte Community. Die Anzahl von geschlossenen Bugs ist 2019 signifikant in die Höhe gegangen, was dabei geholfen hat, die Eclipse IDE besser zu machen.

Das flutscht – Performance der Eclipse IDE

Die Eclipse IDE 2019-12 läuft inzwischen richtig schnell. Ein minimales Eclipse kann inzwischen in weniger als fünf Sekunden starten. Auch die Benutzung ist inzwischen überall deutlich schneller. Beispielsweise war das Tabswitchen vor 2019-12 deutlich langsamer als z. B. in Visual Studio Code (VS Code). Das wurde mit dem Performancemesstool YourKit mehrfach gemessen und optimiert, sodass die Performance bei Tabwechsel nun mit VS Code vergleichbar ist. Das Eclipse Git Tooling ist inzwischen ebenfalls hochoptimiert und bremst die IDE nicht mehr aus. Operationen wie Compare oder das Scrollen in einem großen File unter Mac OS sind ebenfalls endlich sehr viel schneller. Das zeigen auch die wieder aktivierten Performancetests, die immer einen Vergleich zum letzten Release zulassen (Abb. 2).

Abb. 2: Wieder aktivierte Performancetests

Alle Verbesserungen aufzuzählen, würde den Rahmen dieses Artikels sprengen, aber an einer Vielzahl von Stellen wurden Verbesserungen vorgenommen. Dadurch ist die IDE insgesamt reaktiver. Und keine Frage: Ein schnelles Tool macht einfach mehr Spaß.

Usability und Funktionalität in der Eclipse IDE

Natürlich unterstützt Eclipse die aktuelle Java-Version, was durch den dreimonatigen Releasezyklus der Entwicklungsumgebung leichter machbar ist. Schön ist, dass inzwischen auch Microsoft im Java-Projekt mitarbeitet, da das Unternehmen den Eclipse-Compiler für Visual Studio Code nutzt. Somit kann man als Java-Entwickler inzwischen auch VS Code für Java einsetzen. Unter der Haube nutzt man dann immer noch den ausgereiften und schnellen Eclipse-Compiler.

Im Bereich der Usability wurde erneut darauf Wert gelegt, dass die Texte in der IDE kürzer werden. Die IDE respektiert, dass Entwickler anderes zu tun haben, als lange Dialogtexte zu lesen, und fokussiert sich auf das Wesentliche (Abb. 3 und 4).

Abb. 3: Beispiel 1 für kürzere Dialogtexte

 

Abb. 4: Beispiel 2 für kürzere Dialogtexte

Außerdem wurden einige Icons in Eclipse angepasst, beispielsweise sieht das Filtericon nicht mehr aus wie … ja, was sollte das alte Icon eigentlich darstellen? Auf jeden Fall sieht es nunmehr tatsächlich aus wie ein Filtericon.

Auch das View-Menü wurde auf ein Kebab Menu umgestellt, das die Benutzer von ihrem Smartphone oder ihren Webapplikationen gut kennen (Abb. 5).

Abb. 5: Das Kebab Menu

Fehler- und Warnmeldungen kann man sich jetzt auch in den Text einblenden lassen, Eclipse nennt das Code Mining (Abb. 6), in VS Code heißt es Code Lenses.

Abb. 6: Code Mining

In den Eclipse-Plug-in-Tools wurde ein uralter Bug gefixt, der Kunden oft verzweifeln ließ: Um vermeintliche Zyklen aufzulösen, musste man Projekte mehrfach manuell bauen. Das war in vielen Fällen nur ein Fehler, der nun gefixt wurde. Einmal bauen reicht jetzt aus.

Ein weiterer Punkt: Bei Save Actions bzw. Möglichkeiten, seinen Source Code automatisch aufzuräumen, sind viele neuen Optionen hinzugekommen (Abb. 7).

Abb. 7: Neue Optionen bei Save Actions

Nicht zuletzt wurde das Dark Theme weiter verbessert, es werden nicht mehr so viele verschiedene Dunkeltöne verwendet und das Styling ist sehr viel schneller geworden.

Ausblick auf 2020-03

In Release 2020-03 kann man weitere Performanceverbesserungen erwarten. Dann sollte auch der Patch eingebaut worden sein, der die Java Code Completion asynchron machen wird. Das bedeutet, dass auch bei zig Gigabyte an verwendeten Libraries die IDE bei CTRL + Space nicht mehr einfrieren wird. Generell werden mehr Operationen asynchron ausgeführt, viele weitere neue Funktionalitäten hinzugefügt und das Dark Theme wird weiterhin verbessert werden.

Zusammenfassung

Zusammenfassend lässt sich sagen, dass es im Eclipse-Projekt ziemlich rund läuft. Der dreimonatige Releasezyklus hat eine neue Dynamik entfaltet, von der die Benutzer profitieren. Nutzer von Uraltversionen wie Oxygen, Mars, Neon oder Photon sei es ans Herz gelegt, auf das neueste Release zu wechseln, damit auch sie die neue IDE genießen können.

Geschrieben von
Lars Vogel
Lars Vogel
Lars Vogel ist Geschäftsführer der vogella GmbH, die Kunden im Bereich Eclipse, Android und anderen Themen unterstützt. Als Project-Management-Committee-Mitglied, Eclipse-Projektleiter und Committer hilft er dem Eclipse-Projekt. E-Mail: lars.vogel@vogella.com
Jennifer Nerlich

Jennifer Nerlich leitet bei der vogella GmbH die Forschungsprojekte und ist zusätzlich zuständig für Sales, Marketing und HR.

Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: