Kolumne

Lagebericht Eclipse-IDE: Eine solide Architektur

Simon Scholz, Lars Vogel

In ihrer Kolumne “Lagebericht Eclipse-IDE” geben Lars Vogel und Simon Scholz Einblicke in die aktuellen Arbeiten an der Eclipse-Plattform. In dieser Folge geht es um Grundlagen: Was sind eigentlich Eclipse-Plug-ins, was ist ein Feature, welche Rolle spielen Produkte und Eclipse-Downloads?

Eine solide Architektur

Jede hinreichend erfolgreiche Technologie muss sinnvoll erweiterbar sein. So lässt sich jeder Browser, der sein Downloadvolumen wert ist, durch Plug-ins erweitern: Der Linux-Kernel beispielsweise verfolgt zwar einen monolithischen Ansatz, kennt aber die Kernel-Module; die populären Java-Build-Systeme Maven und Gradle sind Plug-in-basiert und so weiter. Natürlich lässt sich auch die Eclipse-IDE als Vorzeigeprojekt des Open-Source-Bereichs im Java-Umfeld erweitern. Die modulare Struktur von Eclipse ist sicherlich einer der Erfolgsfaktoren der Entwicklungsumgebung. In diesem Kolumnenbeitrag schauen wir uns diese Architektur an und beleuchten die Vor- und Nachteile.

Was sind Plug-ins in Eclipse?

Die kleinste eigenständige Einheit in der Eclipse-IDE sind Plug-ins. Diese können selbstständig entwickelt und installiert werden und erweitern die Eclipse-IDE mit neuen Funktionen. Hierzu stellt die Eclipse-Plattform, aber auch unzählige andere Eclipse-Projekte, Schnittstellen zur Erweiterung zur Verfügung.

Die OSGi-Spezifikation liefert eine Definition für ein Modulsystem für die Java-Laufzeit. Die Eclipse-IDE selbst nutzt die OSGi-Referenzimplementierung Equinox als Laufzeitumgebung. Diese Umgebung ist so flexibel und erweiterbar, dass man auch zur Laufzeit der Eclipse-IDE Plug-ins hinzufügen und starten kann. Die Plug-ins müssen lediglich in der Target-Plattform der IDE bereitstehen, die als Pool von Plug-ins der IDE fungiert.

Plug-ins (bzw. OSGi Bundles) sind im Prinzip normale Java-Projekte mit der Ausnahme, dass die MANIFEST.MF-Datei zusätzliche Metainformationen enthält. Im Umkehrschluss heißt dies, dass man auch in ganz normalen Java-Projekten OSGi Bundles als Bibliotheken verwenden kann, wo dann diese OSGi-Metainformationen entsprechend ignoriert werden. So hat das Eclipse-Projekt viele Anbieter von Bibliotheken überzeugen können, OSGi-Metainformationen hinzuzufügen, sodass sich diese auch im OSGi-Umfeld nutzen lassen. Ein solches OSGi-MANIFEST.MF kann aussehen wie in Listing 1.

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: %pluginName
Bundle-SymbolicName: org.eclipse.core.databinding.example
Bundle-Version: 1.6.0.qualifier
Bundle-ClassPath: .
Bundle-Vendor: %providerName
Bundle-Localization: plugin
Export-Package: org.eclipse.core.databinding,
  org.eclipse.core.databinding.conversion;x-internal:=false
Require-Bundle: org.eclipse.equinox.common;bundle-version="[3.2.0,4.0.0)",
  org.eclipse.core.databinding.observable;bundle-version="[1.3.0,2.0.0)";visibility:=reexport,
  org.eclipse.osgi.framework.log;version="[1.0.0,2.0.0)";resolution:=optional
Bundle-RequiredExecutionEnvironment: JavaSE-1.8
Bundle-Activator: org.eclipse.core.internal.databinding.Activator
Bundle-ActivationPolicy: lazy

Der wohl größte Unterschied zu normalen Java-Projekten ist, dass Abhängigkeiten nicht etwa in einer pom.xml-Datei (für das Maven-Build-System) oder einer build.gradle-Datei (für das Gradle-Build-System) spezifiziert werden, sondern in der MANIFEST.MF-Datei. Neben der MANIFEST.MF-Datei kann ein Plug-in auch eine plugin.xml-Datei haben, die genutzt werden kann, um wiederum andere Plug-ins hinsichtlich ihrer Funktionalität zu erweitern. Weitere Informationen und Bespiele, wie man eigene Erweiterungen für die Eclipse-IDE erstellt, können Online gefunden werden.

Nun sind Plug-ins eine nette Sache, aber meistens werden für Eclipse mehrere Plug-ins benötigt, um eine runde Funktionalität zu liefern. An dieser Stelle kommen die Features ins Spiel.

Was ist ein Feature?

Generell ist es erst das Zusammenspiel von mehreren Plug-ins, die eine gewisse Funktionalität bereitstellen. Featureprojekte kann man als Container oder Composite für mehrere einzelne zusammengehörige Plug-ins verstehen. In den meisten Fällen, sei es über den Eclipse Marketplace oder über eine p2-Updateseite, werden Features anstelle einzelner Plug-ins installiert. Durch die Verwendung von Features können die Maintainer von Projekten einfach Features anbieten, bei denen sich unter der Haube die Plug-ins ändern können, d. h. wegfallen oder hinzukommen. Somit ist sichergestellt, dass man bei der Verwendung von Features immer die korrekten Plug-ins installiert hat.

Abb. 1: Im Menü „Help | About Eclipse SDK“ unter „Installation Details“ findet man eine Auflistung der Features, die in der Eclipse-IDE installiert sind

Abb. 1: Im Menü „Help | About Eclipse SDK“ unter „Installation Details“ findet man eine Auflistung der Features, die in der Eclipse-IDE installiert sind

Die Bedeutung von Produkten und Eclipse-Downloads

Ein Produkt beschreibt eine Eclipse-basierte Applikation, wie auch die Eclipse IDE selbst eine ist, und definiert zusätzliche Metainformationen über das Produkt. Es ist somit der nächstgrößere Container, der entweder aus Plug-ins oder besser aus Features besteht (Abb. 2).

Abb. 2: Ein Produkt ist ein nächstgrößerer Container, der entweder aus Plug-ins oder aus Features besteht

Abb. 2: Ein Produkt ist ein nächstgrößerer Container, der entweder aus Plug-ins oder aus Features besteht

Die Produktdefinition ist nur eine Konfigurationsdatei, die beim Build einer Eclipse-RCP-Applikation ausgelesen wird, aber selbst nicht Teil des fertigen Produkts ist. Vielmehr wird in dieser Definition eine Implementierung des IApplication-Interface referenziert sowie ein Produktname und eine Produkt-ID vergeben. Weitere Informationen, die im Produkt spezifiziert werden, sind das Branding (Icons, Splash Screen, Launcher Name etc.), Lizenzinformationen, aber auch Starteigenschaften und VM-Eigenschaften.

Die Downloads, die Eclipse bereitstellt, basieren auf Produkten und sind Teil des Eclipse-Packaging-Projekts. Diese Projekte überlegen sich, welche Eclipse-Features wohl für verschiedene Anwendungsszenarien interessant sind und stellen dann entsprechende Downloads zur Verfügung. So hat die Entwicklungsumgebung für C-Programme die Features vom Eclipse CDT sowie EGit im Bauch, und das Eclipse-Java-EE-Package enthält die Java-Tools, Maven-Build-Support, Git etc.

Wieso erweitern schlecht sein kann

Natürlich haben erweiterbare Systeme einen gravierenden Nachteil: Im Prinzip kann sie jeder erweitern, und eine schlecht programmierte populäre Erweiterung kann eine Plattform schlecht machen. Dazu kam es vor etwa fünf Jahren, als Google seine Android-Tools noch hauptsächlich auf Basis von Eclipse entwickelte. Die schlechte Qualität und die geringe Geschwindigkeit der Android Tools hinterließen bei vielen Android-Entwicklern damals das Gefühl, dass Eclipse sehr buggy und langsam sei. Der Eindruck wurde 2012 auch durch die Umstellung auf Eclipse 4 verstärkt, der ebenfalls kurzfristig einen Einbruch in der Qualität der Eclipse-IDE nach sich zog. Zum Glück basieren die qualitativ immer noch schlechten Android-Tools inzwischen auf IntelliJ, und die berechtigte Unzufriedenheit der Nutzer von Android Studio bezieht sich sich nun auf IntelliJ.

Dennoch kann natürlich ein Plug-in für Eclipse, das sich in den Compiler reinhängt, die IDE ausbremsen und mit Jobs, die sich nicht abbrechen lassen, bzw. NullPointerExceptions nur so um sich werfen und damit den Gesamteindruck der Eclipse-IDE verschlechtern.

Um dem entgegenzuwirken, hat das Eclipse-Team die ersten Maßnahmen schon im Eclipse-4.5-(Mars-)Release getroffen. Mit 4.5 wurde ein UI-Freeze-Monitor eingeführt, der es erlaubt, Fehlermeldungen mit den entsprechenden Stacktraces zu schreiben, wenn ein Plug-in den UI-Thread zu lange blockiert. Für die Verwendung und Aktivierung dieses Monitors siehe hier.

Für 4.6.1 ist geplant, dieses Konzept auf Eclipse-Hintergrundjobs zu übertragen. Reagiert ein Job nicht, wenn der Benutzer versucht diesen abzubrechen, wird zukünftig auch eine Fehlermeldung geschrieben. Über das automatische Fehlerreporting-Tooling, das inzwischen Teil fast jedes Eclipse-Downloads ist, werden diese Fehler dann gesammelt und dem entsprechenden Projekt zur Verfügung gestellt.

Nicht doch lieber alles aus einem Guss?

Fans von anderen IDEs werden jetzt eventuell denken, dass der herstellerorientierte Ansatz von IntelliJ doch der bessere ist. Da ist jemand, der Geld kassiert und dafür eine IDE liefert, die in sich abgestimmt ist. Zunächst einmal sollte man hier festhalten, dass es natürlich Geschmacksache ist, welchen Ansatz man bei seiner IDE bevorzugt. Will man Software, die von einer Firma kontrolliert wird, oder lieber Open-Source-Software?

Hat man diese eher theoretische Diskussion hinter sich gebracht, muss man objektiv feststellen, dass jede Software, die hinreichend erfolgreich sein will, erweiterbar sein muss. Docker mit seinen vielen Erweiterungen ist ein aktuelles Beispiel. So wird inzwischen auch IntelliJ IDEA erweitert. Als prominentes Beispiel sei Android Studio genannt. Da IntelliJ aber von der Basisarchitekutur nicht auf Erweiterungen ausgelegt ist, haben Erweiterer wie Android Studio natürlich mit erheblichen Problemen zu kämpfen. Ohne Details zu wissen, ist doch stark zu vermuten, dass dieser Fakt zur Instabilität des ersten offiziellen Releases von Android Studio und der vierjährigen Entwicklungszeit beigetragen hat.

Von daher glauben wir, dass Erweiterbarkeit ein Basisbestandteil einer erfolgreichen Software sein muss. Nur durch eine solide, komponentenbasierte Architektur ist es möglich, dass einzelne Entwickler und neue Entwicklergruppen sich einzelner Komponenten annehmen und diese weitertreiben. Eine komponentenbasierte Architektur stellt zudem sicher, dass man einzelne Komponenten austauschen oder erneuern kann, ohne das Gesamtsystem komplett überarbeiten zu müssen.

Die Eclipse-IDE ist hier sehr gut aufgestellt. Insbesondere wurde die Modularität mit dem Release von Eclipse 4.x noch einmal auf moderne Entwicklungskonzepte umgestellt, z. B. mit der Verwendung von Dependency Injection. Die solide Erweiterbarkeit hat auch dazu geführt, dass neue Firmen, wie Google, Red Hat, vogella und viele einzelne Entwickler, sich der IDE zusammen mit IBM angenommen haben. Die aktuelle Entwicklerverteilung kann über Abbildung 3 eingesehen werden.

Abb 3: Die aktuelle Entwicklerverteilung

Abb 3: Die aktuelle Entwicklerverteilung

Mit Eclipse Mars und dem kürzlich erschienenen Release 4.6 (Neon) kann Eclipse erneut seine Stärken ausspielen: Eclipse 4.5 war schon ein wichtiges und beeindruckendes Release, und Eclipse Neon setzt die Messlatte weiter nach oben. Doch nach dem Release ist vor dem Release: Die Arbeiten am Neon-Nachfolger Oxygen laufen bereits: Da die neuen Committer sich in den letzten ein bis zwei Jahren gut eingearbeitet haben, ist geplant, dort einige größere Baustellen anzugehen.

Geschrieben von
Simon Scholz
Simon Scholz ist Eclipse Platform und e4 Committer. Er entwickelt auch am PDE, und Eclipse Gradle Tooling mit und nutzt seine langjährige Eclipse-RCP- und Plug-in-Erfahrung für Kundenimplementierungen, Eclipse-RCP-Workshops und Schulungen. Zudem hält er regelmäßig Vorträge auf Softwarekonferenzen bzgl. verschiedener Eclipse-Technologien.
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
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: