Zehn Jahre Simultaneous Release

Eclipse Kepler Rundblick

Holger Voormann

Kepler ist das zehnte Simultaneous Release, die jährliche gemeinsame Veröffentlichung von Software aus 71 Eclipse-Projekten. Von Jahr zu Jahr stieg die Zahl der beteiligten Projekte, doch ausgerechnet beim Jubiläums-Release bleibt sie erstmals konstant (Abb. 1). Wer in diesem zeitlichen Verlauf die erste Hälfte der Gaußschen Glockenkurve ausmacht, der prognostiziert damit das Verschwinden von Eclipse in einem Jahrzehnt. Den Verlauf könnte man aber auch als Erreichen einer Sättigung interpretieren oder – wenn man Parallelen zu 2008 sieht, als Ganymede um bescheidene zwei Projekte wuchs – als kleine Wachstumsdelle. Bevor wir aber über einen Trend spekulieren, schauen wir uns an, welche Veränderungen Kepler bringt.

Eclipse Kepler im Fokus
Das kommende Eclipse Magazin widmet sich in seinem Schwerpunktthema detailliert dem Eclipse Kepler Release Train. Neben dem ausführlichen Artikel „Mein Kepler-Jahresrückblick“ von Holger Voormann finden Sie Beiträge zu den Neuerungen in der 4.3-Plattform, den Java Development Tools, in RAP 2.1 und der Orion IDE. Zudem stellen wir die neuen Projekte Stardust und EMF Diff/Merge vor und präsentieren spannende Erfahrungsberichte über die Umstellung von Eclipse 3.x auf 4.
Eclipse Magazin 5.13 ab 26.7. am Kiosk!

Abb. 1: Kepler, das zehnte Simultaneous Release, mit 71 Projekten wie sein Vorgänger Juno, dessen Projektanzahl nachträglich von 72 auf 71 korrigiert wurde, weil nicht berücksichtigt wurde, dass EMF Query 2 in letzter Minute abgesprungen war [1]

Minus 4

In Juno gab es die Eclipse-Entwicklungsumgebung nicht nur in der Version 4.2, sondern daneben auch in Version 3.8. Wie angekündigt, war dies die letzte 3.x-Version, denn in Kepler wird mit 4.3 nur die 4.x-Linie weitergeführt. Außer dem Eclipse SDK 3.9 sucht man in der Kepler-Liste vier Juno-Projekte vergebens: Xtend , Jetty, Virgo und Runtime Packaging. Xtend ist zwar weiterhin Bestandteil von Kepler, aber nicht als eigenes Projekt, sondern als Teil von Xtext, auf dem es basiert [2]. Die Einsatzbereiche von Xtend und Xtext sind recht unterschiedlich: auf der einen Seite die Programmiersprache Xtend als Alternative zu Java, die nun auch zum Programmieren von Android-Apps geeignet ist, und auf der anderen Seite Xtext, um Editoren und die für Eclipse typische Tool-Unterstützung für eigene domainspezifische Sprachen zu generieren. Trotzdem wurden beide Projekte aus organisatorischen Gründen – derselbe Projektleiter, gemeinsame Entwickler und gleiche Versionierung – wieder zusammengelegt. Ausschlaggebend für das Fehlen des Webservers und Servlet/JSP-Containers Jetty werden wohl lizenzrechtliche Probleme gewesen sein: Jetty 9 implementiert die HTTP-Erweiterung SPDY von Google zum schnelleren Laden von Webseiten und benötigt dazu nicht nur Java 7, sondern modifiziert auch Klassen der Java-Bibliothek, was Eclipse aber verbietet [3]. Der Anfang 2010 gestiftete SpringSource dm Server, der nun Virgo heißt, hatte mit Juno ein sehr kurzes Simultaneous-Release-Gastspiel. Stattdessen möchte sich das Team auf den Long Term Support (LTS) konzentrieren [4]. Das Runtime Packaging (RTP) Projekt war sowohl bei Indigo als auch bei Juno dabei. RTP bietet Basis-Pakete zum Ausführen von Anwendungen, die auf Eclipse beziehungsweise auf Projekten basieren, die zum Top-Level-Projekt RT (Runtimes) gehören. Dazu zählen sowohl das OSGi-Framework Equinox als auch die beiden eben genannten Kepler-Aussteiger Jetty und Virgo. Seit Juno gibt es praktisch keine Änderungen mehr. Alle drei Pakete, zwei 11 beziehungsweise 8 MB große ZIP-Dateien sowie ein auf dem nicht mehr aktuellen Ubuntu 10.10 basierendes Amazon EC2 Image werden außerhalb von Kepler unverändert angeboten.

Plus 4

Die vier Abgänge, Eclipse 3.x nicht mitgezählt, werden durch vier Neuzugänge ausgeglichen. Das neue Projekt mit dem schönen, aber wenig sprechenden Namen Stardust ist kein Eclipse-Eigengewächs, sondern entstand vorletztes Jahr aus der Weiterführung des bis dahin proprietär entwickelten Produkts Infinity Process Platform von SunGard [5]. SunGard leistet weiterhin die Hauptarbeit, verdient aber ansonsten auch durch Dienstleistungen rund um Stardust. Stardust profitiert von der Popularität von Eclipse, und Eclipse kann sich rühmen, ein komplettes Business-Process-Management-(BPM-)Paket im Angebot zu haben [6].

Noch früher als Stardust entstand 2010 das Eclipse-Projekt Sphinx [7]. Der anfängliche Code stammte von der AUTOSAR Tool Platform (Artop). AUTOSAR ist eine Vereinigung von Firmen der Automobilindustrie, was erklärt, warum neben itemis auch BMW eine treibende Kraft von Sphinx ist. In Version 0.7 ist Sphinx zum ersten Mal beim Simultaneous Release dabei. Wie das Extended Editing Framework (EEF), das mit Version 1.2 zum vierten Mal in Folge beim Simultaneous Release dabei ist und hinter dem die Firma Obeo steckt, bietet Sphinx ein Basisgerüst für Eclipse-Desktop-Anwendungen zum Bearbeiteten von auf dem Eclipse Modeling Framework (EMF) basierenden Modellen.

Abb. 2: EMF Diff/Merge (im Vordergrund) beherrscht wie EMF Compare (im Hintergrund) den Drei-Wege-Vergleich

Auch EMF Diff/Merge, der dritte Kepler-Neuling, ist innerhalb von EMF nicht alternativlos [8]. EMF Diff/Merge ist erst seit Juni letzten Jahres ein Eclipse-Projekt und entstand aus einer Code-Spende der Firma Thales. In Kepler ist das Projekt mit Version 0.2 dabei. Überschneidungen gibt es innerhalb von Kepler mit EMF Compare 2.1, an dem die Firma Obeo sehr aktiv entwickelt [9]. Die Oberfläche von EMF Diff/Merge ist dreispaltig aufgebaut: in der linken Spalte das zusammengeführte Modell und in den anderen beiden Spalten die beiden zu vergleichenden Modelle (Abb. 2). Zur Integration in eigene EMF-basierte Anwendungen lässt sich die Diff- und Merge-Strategie entsprechend anpassen.

Wie der Name schon vermuten lässt, ist Maven Integration for Web Tools Platform (m2e-wtp) ein Unterprojekt und eine Erweiterung von Maven Integration (m2e), die die Web Tools Platform voraussetzt [10], [11]. Beide Projekte waren, bevor sie zu Eclipse kamen, das gemeinsame Projekt m2eclipse von Sonatype. Warum das jetzige Ein-Mann-Projekt von Fred Bricon (Red Hat) nicht Teil von m2e ist, sondern im April letzten Jahres ein eigenständiges Projekt wurde beziehungsweise blieb, entzieht sich meiner Kenntnis. In Version 1.0 ist es jedenfalls wie Maven Integration 1.4 Teil von Kepler und dem Download-Paket Eclipse IDE for Java EE Developers. Es sorgt unter anderem dafür, dass in der Entwicklungsumgebung beim Anlegen eines Maven-Projekts eines Web-Archetyps das erzeugte Projekt auch als Web- und nicht nur als Java-Projekt erkannt wird.

[ header = Neues von alten Hasen ]

Neues von alten Hasen

Bei den Java Development Tools (JDT) gibt es wie bei der Plattform hauptsächlich Detailverbesserungen. Das liegt vermutlich daran, dass am Java-8-Support gearbeitet wurde, der jetzt doch nicht kommt, weil Oracle Java 8 auf das erste Quartal 2014 verschob [12]. Das gleiche Problem stellte sich schon einmal 2011 mit Java 7 in Eclipse 3.7 alias Indigo. Damals wurde der Java-7-Support mit dem ersten Service-Release nachgeliefert. Für den Java-8-Support muss man voraussichtlich auf den Kepler-Nachfolger Luna warten oder eine Vorabversion für Kepler installieren, falls sich Java 8 nicht noch weiter verschiebt [13]. Zu den kleineren Verbesserungen zählen neue Code-Assistenten beziehungsweise Korrekturvorschläge, die mit dem Tastenkürzel Strg+1 angezeigt werden. So kann beispielsweise aus einer if-else-Anweisung ein switch-Statement gemacht oder mehrere per „+“ konkatenierte Strings zu einem zusammengefasst werden. Weil ich es für besser lesbar halte, Sonderfälle am Methodenanfang abzuprüfen und gegebenenfalls die Verarbeitung mit return abzubrechen, gefällt mir insbesondere der Quick Assist „Convert to if-!-return“ (Abb. 3). Dass es hierzu keine Reverse-Funktion gibt, passt mir aufgrund meiner Code-Stil-Überzeugung ganz gut in den Kram. Die statische Code-Analyse für mit Null-Annotationen ausgezeichneten Code wurde auf Instanzvariablen ausgedehnt, und Null-Annotationen lassen sich vererben beziehungsweise vom implementierten Interface übernehmen. Die Codeanalyse, die nicht geschlossene Ressourcen aufspürt, berücksichtigt nun auch die bekannten Frameworks von Google und Apache, die das Schließen übernehmen. Bei der Javadoc und Declaration View wird nun bei „Link with Selection“ auch angezeigt, wenn die View der Auswahl nicht folgen kann (Abb. 4). Hoffentlich wird das Konzept auch von anderen Views wie beispielsweise der History View übernommen und es passiert nicht das Gleiche wie bei der praktischen Brotkrümelnavigationsleiste, die den Pfad zum Navigieren oben im Editor als Zeile zeigt und die es seit Eclipse 3.4 leider nur für Java-Editoren gibt.

Abb. 3: Bei der Javadoc und der Declaration View ändert sich das „Link with Selection“-Icon, wenn die View der Auswahl nicht folgen kann

Abb. 4: Die neuen View „Plug-in Image Browser“ zeigt vorhandene Icons an

Fast alle Entwickler der Web-Entwicklungsumgebung Orion sind von IBM, einige davon arbeiteten früher für das Eclipse-Platform-Projekt. Juno enthielt noch Orion 0.5, dann ging es Schlag auf Schlag: Orion 1.0 im Oktober, 2.0 im Februar und 3.0 mit Kepler im Juni. Wer Orion kennenlernen oder sich den aktuellen Stand anschauen will, kann dies kostenlos auf http://orionhub.org tun. Wer sich zum ersten Mal einloggt, sieht eine fast leere Webseite vor sich. In der Kopfleiste gibt es jeweils links und rechts eine Schaltfläche. Mit der linken kann man unter anderem Git-Repositories klonen, mit der rechten Einstellungen wie das Aussehen der Oberfläche verändern und – das ist die Besonderheit von Orion – Plug-ins installieren. Für das Editieren von HTML und JavaScript ist Orion schon recht brauchbar. Die vom Texteditor von Eclipse bekannten Funktionen sind unter den bekannten Tastaturkürzeln zu erreichen, wie beispielsweise Suchen (Strg+H), Finden (Strg+F) oder Verschieben von Zeilen (Alt+Pfeiltaste hoch/runter). Die Codevervollständigung (Strg+Leertaste) enthält auch Vorlagen, z. B. für for-Schleifen, ist aber mit der eines Java-Editors einer aktuellen IDE nicht zu vergleichen. Zu loben ist die im Vergleich zu vielen anderen Kepler-Projekten sehr gute Hilfe, auch wenn sie nicht überall aktuell ist und die Screenshots bisweilen bereits veraltete Oberflächen zeigen [14].

RAP, mit dem man mit wenigen Code-Änderungen aus Eclipse-basierten Desktop-Anwendungen Webanwendungen machen kann, steht nicht mehr für Rich Ajax Platform, sondern für Remote Application Platform. Das Web ist nicht mehr die einzige Zielplattform [15]. Das Protokoll ist inzwischen komplett JSON-basiert, und mit Tabris (ehemals RAP mobile) gibt es von der Firma EclipseSource einen kommerziellen RAP-Client für iOS und Android.

Wem diese Auswahl an Neuigkeiten der 71 Kepler-Projekte noch nicht reicht, dem sei Ian Bulls Countdown empfohlen, in dem er seit 2007 seine Top-Ten der Verbesserungen des jeweiligen Simultaneous Release präsentiert [16].

[ header = Change happens ]

Change happens

Die Anzeichen mehren sich, dass sich Eclipse vom Anbieter rund um die leicht erweiterbare Entwicklungsumgebung und Plattform weg und hin zu einer Apache-Software-Foundation-ähnlichen Organisation verändert, die Open-Source-Projekte mit dem Fokus kommerzieller Nutzbarkeit fördert. Wenn ein so bekanntes Nicht-Eclipse-Projekt wie JRuby seine Lizenz von Common Public License (CPL) zur Eclipse Public License (EPL) wechselt, ist das für mich beispielsweise so ein Hinweis [17]. Dr. Wagstrom, ein Mitarbeiter des IBM Yorktown Forschungszentrums, prognostiziert, dass in fünf Jahren zu 50 Prozent Web-basierte Entwicklungsumgebungen genutzt werden [18]. Davon ist sicherlich auch sein Arbeitgeber überzeugt, sonst würde IBM kaum eine zweistellige Anzahl an Entwicklern für Orion abstellen. Orion besteht aus zwei Teilen, dem Server in Java und dem Client in JavaScript. Eine alternative Implementierung des Servers auf Basis von Node.js und damit in JavaScript gibt es aber auch schon als Bestandteil des Orion-Projekts [19]. Orion kann also auch ohne Java und OSGi. Auch die Eclipse-Projekte Hudson und Vert.x bestehen weder aus Eclipse-Plug-ins noch aus OSGi-Bundles. Man könnte sie als nicht-Eclipse-basierte Eclipse-Projekte bezeichnen. Sie lassen sich dadurch nur schwer mit Produkten anderer Eclipse-Projekte kombinieren. Orion, Hudson und Vert.x sind im Web zuhause, aber auch Apps für iOS, Android und Windows 8 nehmen klassischen Desktop-Anwendungen, also dort, wo Eclipse seine Wurzeln und Stärken hat, Marktanteile ab. Zwar hat sich Eclipse bei Unternehmen mit firmeninternen Eclipse-Rich-Client-Platform-(RCP-) Anwendungen besonders tief eingegraben, aber der Trend ist unverkennbar. Konnte man bisher noch argumentieren, dass Eclipse zur Entwicklung von Android-Apps notwendig sei, gilt das Argument seit Mai diesen Jahres nicht mehr, als Google mit seinem auf IntelliJ basierenden Android Studio überraschte [20]. Und das, obwohl Google erst im Oktober letzten Jahres seine Mitgliedschaft auf die höchste Stufe, Eclipse Strategic Member, upgradete und damit diesen erlauchten Kreis auf elf erweiterte [21]. Dass Eclipse sogar auf dem so beliebten kreditkartengroßen Bastel-Computer Raspberry Pi läuft, ist da ein nur ein kleiner Trost [22]. Auch die im Vergleich zum Vorjahr gesunkene Zufriedenheit mit Eclipse bei der jährlich stattfindenden Umfrage verstehe ich als Warnhinweis, Eclipse möge sich mehr um seine Java IDE kümmern (Abb 5).

Abb. 5: Bei der Eclipse Community Survey 2013 gaben rund 80% der 920 Befragten an, mit Eclipse zufrieden oder sehr zufrieden zu sein. In den Jahren zuvor waren es knapp 90%. [22]

Meine Prognose bezüglich der zukünftigen Anzahl der Projekte liegt zwischen Stagnation auf hohem Niveau und verhaltener Zunahme. Der Anteil derjenigen Projekte, die Erweiterungen für die Entwicklungsumgebung oder Komponenten für Desktop-Anwendungen liefern, wird vermutlich abnehmen. Sofern unter den nicht auf der Eclipse-Plattform basierenden Projekten solche sind, die das Eclipse-Prinzip auf Tablets oder ins Web bringen, würde mich das freuen, denn für mich ist Eclipse vor allem eine effiziente, flexibel erweiterbare Arbeitsumgebung, in der meine Auswahl an Tools zu einem einzigen mächtigen Werkzeug verschmilzt. Eclipse ist für mich die Integration, die ich vermisse, wenn ich auf meinem Tablet per Multi-touch immer nur eine App gleichzeitig bedienen kann. Eclipse ist für mich die Auswahlmöglichkeit, die mir genommen wird, wenn Yahoo, Google, Microsoft oder Facebook andere Dienste aufkaufen und assimilieren und ich nicht auf Integration verzichten will. Eclipse ist für mich Termintreue, die ich vermisse, wenn Java 8 verschoben wird und es alle so hinnehmen. Auch wenn ich so manches an Eclipse auszusetzen habe, ist Eclipse aber auch die Gemeinschaft, in der ich mich als Committer, als Contributor und als Anwender wohl fühle. Egal was die Zukunft bringt, zehn Jahre Simultaneous Release sind ein Grund zum Feiern. Zehn Jahre Simultaneous Release, das sollen die anderen erst mal nachmachen!

Geschrieben von
Holger Voormann
Holger Voormann
Holger Voormann: irgendwas mit Eclipse; früher festangestellt, seit 2010 freiberuflich; Eclipse Vex (a Visual Editor for XML) Committer, aber länger inaktiv; dafür kleinere Code-Beiträge für die Eclipse-Plattform, aber nicht als Committer; bloggt unregelmäßig (eclipsehowl.wordpress.com); antwortet nicht immer auf E-Mails (eclipse@voormann.de) und auf Tweets (@howlger)
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.