Eclipse 4 - die nächste Generation der freien IDE
Nicht nur als IDE, auch als Plattform erfreut sich Eclipse in den letzten Jahren zunehmender Beliebtheit. Mit e4 versucht die Eclipse-Community zurzeit den Weg für die nächste Generation der Applikationsplattform - Eclipse 4 - zu ebnen.
- Benjamin Muskalla
Nicht nur als IDE, auch als Plattform erfreut sich Eclipse in den letzten Jahren zunehmender Beliebtheit. Dass die Rich Client Platform, kurz RCP, initial aus einem Entwicklungswerkzeug entstanden ist, merkt man allerdings heute noch. Mit e4 versucht die Eclipse-Community zurzeit den Weg für die nächste Generation der Applikationsplattform – Eclipse 4 – zu ebnen.
Im Juli 2009 war es soweit – die offizielle Technical Preview von e4 wurde der Öffentlichkeit vorgestellt. Der Codename e4 steht für konzeptionelle und technische Innovation der Technikplattform Eclipse 4. Nach vorangegangenen Ideen und Diskussionen auf diversen Konferenzen hatten die Entwickler einen ersten gemeinsamen Nenner für die nächste Generation der Plattform vorgestellt. Zu beachten ist allerdings, dass es sich bei e4 0.9, so die aktuelle Version, um eine reine Technical Preview handelt. Zwar wird die Community angeregt, erste Migrationsversuche zu unternehmen, das neue Eclipse sollte jedoch nicht produktiv eingesetzt werden.
Die aktuellen e4-Entwicklungen umfassen größtenteils den eigentlichen Runtime-Aspekt von Eclipse, nicht welche Funktionen in der IDE später zu finden sind. Mit der Technical Preview erreichten die Projektbeteiligten das erste Ziel auf dem Weg zur nächsten Version: self-hosting – sprich Eclipse 4.0 mit e4 zu entwickeln. Die Entwickler für die nächste große Version der IDE planen, dass die erste finale Version im Juli 2010 erscheinen wird.
Services – aber in kleinen Dosen
Eines der größten Probleme der heutigen Rich Client Platform ist ihre Komplexität. Durch ihre Historie als Applikationsplattform für die Eclipse-IDE kamen immer mehr APIs hinzu, um RCP als IDE-unabhängige Plattform zu etablieren. Zu konstatieren ist zudem, dass RCP durch seine für den Produktiveinsatz freundliche Lizenz schnell in kommerzielle Produkte einfloss. Das führte unter anderem dazu, dass die APIs bis heute zu pflegen sind, um die Rückwärtskompatibilität zu wahren. Viele Entwickler, die sich in RCP einarbeiten, stoßen früher oder später an einen Punkt, an dem sie nicht sicher sind, welchen Weg sie gehen sollen. Es gibt einfach zu viele Mittel, bestimmte Ziele zu erreichen.
Des Weiteren sind in den letzten Jahren neue Anforderungen aufgetreten, die es umzusetzen gilt, allerdings zur aktuellen Architektur der Plattform im Widerspruch stehen. Das umfasst unter anderem den Einsatz von Eclipse in anderen Anwendungsbereichen wie auf Servern oder Mobilgeräten. Mit Eclipse 4 versucht man, genau den Problemen auf den Grund zu gehen und es zu ermöglichen, Plug-ins und somit RCP-Applikationen mit weit weniger Aufwand zu schreiben. Getreu dem Motto Alan Kays: "Einfache Dinge sollten einfach sein, komplexe Dinge möglich."
Eclipse ist zwar seit Version 3.0, dank OSGi als Komponentenmodell, modular gestaltet. Jedoch sind einige Teile der Plattform bis heute noch relativ monolithisch. Durch den exzessiven Einsatz von OSGi-Bordmitteln soll sich bei Eclipse 4 eine bessere Modularisierung des Eclipse-Kerns erreichen lassen. Die Plattform versucht sich mehr auf ihre eigentlichen Aufgaben zu konzentrieren und erweiterte Funktionen in andere Komponenten (Bundles) auszulagern. Im e4-Kontext spricht man gerne von "the 20 things", also 20 Dingen, die für eine Applikationsplattform am wichtigsten sind. Sie umfassen neben Standardaufgaben wie Fehlerbehandlung und Logging auch altbekannte Konzepte wie den Lebenszyklus von Editoren, lang laufende Operation und zudem Konzepte der Oberflächengestaltung.
Unter dem Motto "Platform as a Service" sollen die Komponenten besser als eigenständige Services miteinander arbeiten, ohne den Preis von Abhängigkeiten zwischen den Komponenten zu zahlen. Konzepte wie Singletons haben die Entwickler komplett aus dem Eclipse-Umfeld verbannt und durch eine neue Strategie ersetzt – den "Context". Er vermittelt zwischen den Verbrauchern und Anbietern unterschiedlicher Services beziehungsweise kann die Services auffinden, auch ohne direkte Abhängigkeiten.
Um die Aufgabe zu lösen und die Abhängigkeiten als Verbraucher solcher Services so gering wie möglich zu halten, wurde das Dependency Injection (DI) Pattern zum Teil der e4-Kernarchitektur. Es erlaubt, dass harte Abhängigkeiten auf bestimmte Teilsysteme nicht nötig sind, sondern sich alle Metadaten und Services über den Context injizieren lassen. Um nicht eine neue DI-Form zu erfinden, zieht man als Grundlage den Java Specification Request (JSR) 330 – "Dependency Injection for Java" – heran, den seit kurzem offiziellen Java-Standard für DI.
Falls man als Verbraucher nicht auf das Pattern angewiesen sein möchte, erlaubt die Context-Architektur, DI auch programmatisch abzufragen. Somit lassen sich je nach Anwendungsfall andere Services an den Consumer herantragen, ohne dass er explizit vom Serviceanbieter abhängt. Das erlaubt eine weitaus höhere Flexibilität der einzelnen Komponenten und fördert die Wiederverwendung der Komponenten in anderen Anwendungsszenarien. Auch erste Schritte Richtung Tooling-Unterstützung für Dependency Injection haben die Entwickler getätigt. Sie sehen viel versprechend aus.
Beim Thema Eventhandling hat sich bei e4 im Gegensatz zu seinem Vorgänger einiges verändert. Bei Eclipse 3.x war es Usus, eine schier unüberschaubare Anzahl an Eventhandlern zu registrieren. Mit e4 wurde ein neuer Event-Bus eingeführt, der über das typische Publish/Subscribe-Muster die Events an interessierte Handler verteilt.
