Bei Veröffentlichung dieser Zeilen genießt ihr hoffentlich gerade die Neuerungen von Eclipse 4.7. Unterdessen ist das Plattformteam natürlich schon dabei, an den kommenden Versionen 4.7.1 und 4.8 zu arbeiten. Diesmal geht es im Lagebericht um einen Ausblick auf das, was für das nächste Release geplant ist. Ob diese Änderungen dann aber tatsächlich umgesetzt werden, hängt natürlich unter anderem von euren Beiträgen ab. Den Unterschied zu einem Projekt, das von einem einzigen Unternehmen geführt wird, sieht man aber nicht nur daran. Auch organisatorisch ist das Eclipse-Ökosystem nicht statisch, sondern einem steten Wandel unterworfen.

So hat Thomas Watson von IBM vor Kurzem vorgeschlagen, Equinox und p2 wieder zurück zur Plattform zu bringen [1]. Equinox wurde in der Vergangenheit aus dem Platform-Projekt herausgelöst und dem Top-Level-Projekt Runtime zugeführt. Leider gibt es nur wenige Entwickler, die sich aktiv um Equinox kümmern, und für p2 leider noch weniger. Von daher wird das Equinox-Projekt, sofern es keinen Widerspruch gibt, wieder mit dem Plattformprojekt zusammengeführt. Durch diesen Schritt kann dann auch das Führungsteam helfen, neue Entwickler für die Projekte Equinox und p2 zu begeistern. Versuche, neue Committer zu p2 zu bringen, wurden ja leider in der Vergangenheit blockiert [2].

Das Google-Team hat sich sehr zu meinem Bedauern vom Eclipse-Projekt offiziell verabschiedet. Über interne Prozesse gibt Google freilich offiziell keine Auskunft, Gerüchten zufolge haben sie aber ein internes, textbasiertes Refactoring-Tool entwickelt. Dieses soll dabei behilflich sein, Änderungen an der großen Codemasse bei Google durchzuführen.

Zurzeit wird im Plattformteam ebenfalls diskutiert, ob man nicht auch die Subprojekte zusammenlegen sollte. Die Projekte SWT, Platform UI usw. wären dann ein einziges großes Projekt. Eventuell könnte man dann sogar das Plug-in Development Environment und die Java Development Tools integrieren. Den existierenden Committern würde es auf diese Weise viel leichter fallen, in einer fremden Codebasis auf die Schnelle kleinere Änderungen durchzuführen. Neue Contributors könnten sich zudem viel schneller eine Historie von Codebeträgen aufbauen, die ihnen dann auch den Committer-Status ermöglichen würde. Prinzipiell wäre das Zusammenführen der Projekte definitiv eine sinnvolle Vereinfachung des Projekts. Ich hoffe jedenfalls sehr, dass es klappen wird.

Aufräumen für Eclipse 4.8: Erst die Arbeit...

Den Beginn eines neuen Releases nutzen einige Entwickler, etwa das Team rund um Alexander Kurtakov von Red Hat und das Team der vogella GmbH, um intensive Aufräumarbeiten am Code durchzuführen. Auch das Team von IBM treibt in diesem Zusammenhang einige Themen voran, z. B. ist das Entfernen des uralten XULRunner aus dem Code des Standard Widget Toolkit (SWT) in Bearbeitung. In vielen Teilen der Codebasis von der Plattform werden außerdem veraltete Codekonstrukte durch moderne ersetzt. Als Beispiel sei hier der veraltete StringBuffer genannt, den wir durch den schnelleren StringBuilder ersetzen. Im Vordergrund steht hier wie immer die zukünftige Wartbarkeit, die Verbesserung der Performance und das Hübschmachen für neue Contributors.

...dann das Vergnügen: Erweiterungen, Tipps und Tricks

Leider müssen wir bei Kunden oft sehen, dass diese recht wenig über die IDE wissen. Das gilt leider auch für andere IDEs wie Android Studio. Wer bei Twitter ist und gerne mehr über den Umgang mit ­Eclipse erfahren möchte, sollte dem Account @EclipseJavaIDE [3] folgen, über den Eclipse-Experten regelmäßig Tipps zur Verwendung der Eclipse IDE geben. Sopot Çela von Red Hat plant außerdem, für Eclipse 4.8 eine Funktion zu schreiben, die jedem Nutzer auf täglicher Basis wertvolle Tipps geben kann. Hoffentlich wird das helfen, Eclipse-Benutzer zu effizienteren Entwicklern zu machen.

Eines der coolsten Features für eine erweiterbare IDE wird ebenfalls weiterentwickelt: Der Generic Editor, der es Nutzern erlaubt, Erweiterungen für Programmiersprachen relativ leicht dem existierenden Editor hinzuzufügen. Red Hat hat angefangen, ihn für ihre Editoren im Linux und Docker Tooling zu adaptieren. Dabei sind einige Lücken aufgefallen, an deren Schließung für Eclipse 4.8 das Team von Red Hat derzeit arbeitet. Sobald die Lücken geschlossen sind, werden die alten Editoren verworfen und es wird nur noch der Generic Editor verwendet.

Equinox hat übrigens direkt zu Beginn der Arbeiten an der neuen Eclipse-Version auf das OSGi Framework R7 migriert, wodurch Eclipse 4.8 einen modernen Unterbau bekommen hat. Hier werden sich in Zukunft viele Neuerungen abspielen, die sicherlich einen eigenen Kolumnenbeitrag wert sind.

Für das Plus an Nutzerfreundlichkeit

Das Team der vogella GmbH arbeitet nach wie vor besessen daran, die Nutzerfreundlichkeit der Eclipse-Plattform zu erhöhen. Dafür ist zunächst geplant, die Dialoge in der Plattform und dem Git Tooling auf Verben umzustellen und damit deren Nutzung zu erleichtern. Ein Dialog mit der Auswahl Save, Don’t Save und Cancel ist eben einfacher zu bedienen als ein Dialog mit der Auswahl Yes to all, Yes und Cancel. Bei der zweiten Alternative ist man eben gezwungen, den gesamten Dialogtext durchzulesen, wenn man verstehen will, was die einzelnen Buttons eigentlich bedeuten. Auch die Firma Yatta hat eine Usability-Initiative gestartet [4]. Frederic Ebelshäuser und Carsten Reckord arbeiten mit einem Designer daran, bessere UI-Patterns in Eclipse zu identifizieren. Aktuell diskutieren wir (Carsten, Freddy und ich), ob wir diese Initiative zum e4-Projekt überführen können. Vor ein paar Wochen habe ich zudem Kontakt mit dem Team von Glance [5] aufgenommen. Glance stellt eine flexible und erweiterbare Suche für alle möglichen Eclipse-Komponenten zur Verfügung (Abb. 1). Zurzeit sind wir dabei, Glance zum Eclipse-e4-Projekt zu migrieren. Dort soll es qualitativ verbessert und danach zur Plattform migriert werden.

Abb. 1: So funktioniert die Suche mit der Hilfe von Glance

Fazit: Was bringt Eclipse 4.8?

Die oben aufgeführten Änderungen sind zunächst einmal nur das Fundament für die nächste Version von ­Eclipse, denn vieles in einem Open-Source-Projekt passiert spontan. Schön ist jedenfalls zu sehen, dass andere ­Eclipse-Projekte anfangen, die Platform-Verbesserungen von 4.7 zu nutzen. Davon wird sicherlich viel in den Folgereleases von 4.7 und im neuen Eclipse 4.8 landen.

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.

Java EE erblickte 1999 mit der Version 1.0 offiziell das Licht der Welt. Damit feiert die Spezifikation in diesem Jahr ihren achtzehnten Geburtstag. Viel ist in diesen achtzehn Jahren passiert, was Ende der 90er Jahre sicher noch niemand vorhersehen konnte. Wir tragen das Internet in der Hosentasche mit uns herum, Autos fahren fast von alleine und unsere Daten sowie Software liegen irgendwo in dieser ominösen Cloud. Mit diesen Entwicklungen Schritt zu halten ist eine Errungenschaft, die ich Java EE hoch anrechne. Besonders weil Software ja gerne nach achtzehn Monaten schon als veraltet gilt.

Dabei möchte ich nicht behaupten, dass die Enterprise Edition von Java immer an vorderster Front der Neuerungen mitmarschierte. Aber sie hielt Schritt – mal mehr, mal weniger. Was erst recht bemerkenswert ist, wenn man all die firmenpolitischen und strategischen Einflüsse und die sicherlich in den Expertengruppen massenhaft vorhandenen unterschiedlichen Meinungen berücksichtigt. Dabei auch noch den Spagat zwischen Rückwärtskompatibilität, Stabilität und Weiterentwicklung zu meistern, ist keine leichte Aufgabe.

Trotzdem erhält man von Java EE eher den Eindruck eines Hidden Champions als eines gefeierten Stars, trotz seines Alters und der großen Verbreitung. Man liest und hört – auch hier im Java Magazin – deutlich mehr über Spring als über Java EE. Spring muss eben kein Standard sein und kann sich, ohne viel Rücksicht zu nehmen, auf die neuesten Trends stürzen. Neue, glitzernde Dinge interessieren die meisten Menschen deutlich mehr als alte und solide. Damit ist Java EE für mich eher das Arbeitspferd als das Rennpferd der Java-Welt. Es macht zuverlässig seine Arbeit und macht keine Show daraus.

Das ist vielleicht auch einer der Gründe, warum Java EE und seinen Application Servern schon zigmal der Tod prophezeit wurde. Es ist weniger sichtbar und nicht unbedingt der heiße Scheiß. Aber die Expertengruppen und die Community bleiben dran, und oft ist es erstaunlich, was man auch aus manch älterer Technologie noch herausholen kann. Auch Java EE 8 wird eher ein Maintenance-Release als ein großer Schritt nach vorne für die Java-Welt. Aber es legt den Grundstein für Java EE 9, das dann zeigen muss, wie die Zukunft der Enterprise Edition aussehen wird.

Natürlich möchte die Community lieber mehr Weiterentwicklung, mehr neue Features, und das am besten sofort – aber trotzdem bitte Zuverlässigkeit und Stabilität. Auch Java EE soll wie Java selbst in Zukunft einem schnelleren Releasezyklus unterworfen werden. Das ist gut und sinnvoll, da die Veränderungen in der Art und Weise, wie Software geschrieben, ausgeliefert und betrieben wird, eher schneller als langsamer vonstattengehen werden. Um damit Schritt zu halten, muss auch Java EE das Tempo erhöhen. Aber wenn alle Beteiligten bei diesem Tempo mitmachen, steht dem nichts im Wege. Denn auf der soliden Grundlage von Java EE lässt sich sicherlich noch viel Neues schaffen.

Schauen Sie mit uns in die Zukunft!

Melanie Feldmann | Redakteurin