Kolumne

Lagebericht Eclipse-IDE: Neuigkeiten aus dem Eclipse-Projekt und von außerhalb

Lars Vogel

Schneller und schneller dreht sich die Welt der Technologien: Projekte veröffentlichen immer häufiger aktuelle Versionen, neue Programmiersprachen bzw. Modelle werden im Monatsrhythmus ent- und auch wieder verworfen, und natürlich muss sich auch Eclipse an diese modernen Zeiten anpassen. Genau darum geht es in dieser Ausgabe der Eclipse-Kolumne.

Oracle lässt JavaFX offiziell fallen

Wer in den letzten Jahren die Tätigkeiten von Oracle rund um JavaFX genauer beobachtet hat, der hat sicherlich mitbekommen, dass Oracle immer weniger in diese Technologie investiert hat. Immer wieder gab es aufgeregte Forderungen von JavaFX-Begeisterten an Oracles Adresse, endlich klarzustellen, was man mit JavaFX eigentlich vorhabe. Das hat Oracle nun getan, leider fällt das Urteil aber nicht zum Vorteil von JavaFX aus. Ab Java 11 wird JavaFX aus dem JDK ausgegliedert. Wer denkt, dass das noch eine ganze Weile dauern wird, irrt. Oracle hat nämlich beim Veröffentlichen neuer Versionen der Sprache zum Glück auf ein viel schnelleres Modell umgestellt. So kommt es, dass Java 11 bereits im September dieses Jahres fällig ist.

Danach garantiert Oracle nur noch den kommerziellen Support bis 2022. Und danach? Das steht natürlich noch in den Sternen, aber zumindest Oracle scheint sich dann endgültig zurückzuziehen. Wenn sich hier kein neuer finanzstarker Investor findet, wird JavaFX wahrscheinlich den gleichen Weg wie Hudson und OpenOffice gehen, zwei Open-Source-Projekte, die Oracle ja so schlecht geführt hat, dass sie de facto nicht mehr existent sind, bzw. durch neue Projekte (Jenkins und LibreOffice) weitergeführt werden.

Damit stehen Kunden, die auf JavaFX gesetzt haben, jetzt wohl leider im Regen, und als aktiv entwickeltes Java-UI-Framework gibt es dann eigentlich nur noch das Standard Widget Toolkit (SWT). Schade für Kunden, die hier den früheren Aussagen von Oracle vertraut haben, aber aus Sicht des Autors wieder mal ein Grund, lieber auf eine Technologie zu setzen, die nicht von einem Hersteller alleine kontrolliert wird.

Das Auge codet mit

Dunkel ist trendig. Moderne Editoren wie Visual Studio Code kommen deshalb auch standardmäßig mit einem Dark Theme daher. Das Standard-Dark-Theme von Eclipse, das über die Jahre ausgebaut wurde, war … okay. Okay heißt aber eben leider nicht gut. Zum Glück haben sich das Dark Theme und die CSS Engine sich in den letzten Jahren allerdings so weit gemausert, dass immer mehr Eclipse-Platform-Entwickler das Dark Theme auch tatsächlich nutzen bzw. nutzen wollen. Das ist auch der Grund, warum an dieser Stelle recht viel passiert. Schaut man sich das New-and-Noteworthy-Dokument 4.8 M6 von Eclipse an, steht gefühlt beinahe jeder Punkt in Verbindung mit dem Dark Theme und dem Stylingthema. Als Beispiel für die Verbesserungen im Styling kann man etwa die Farbe des Hypertexts im Javadoc Hover anführen, die mit dem Update richtig gut aussieht (Abb. 1 und 2).

Abb. 1: Hypertext-Farbe im Javadoc Hover (vorher)

Abb. 2: Hypertext-Farbe im Javadoc Hover (nachher)

Diese und viele andere Änderungen haben dazu geführt, dass der Autor dieser Zeilen tatsächlich endgültig auf das Dark Theme umgeschaltet hat. Toll ist auch zu sehen, dass Entwickler von Red Hat (z. B. Roland Grunberg und Lucas Bullen), SAP (z. B. Matthias Becker), IBM (z. B. Daniel Megert), der vogella GmbH und freie Committer wie etwa Conrad Groth und Till Brychcy gemeinsam daran arbeiten, das Theme zu verbessern. Zudem haben sich auch neue Contributors wie Robert Munteanu in die Arbeit eingeklinkt.

Wer es dann noch ein wenig besser (aber nicht Open Source) haben will, installiert sich am besten gleich das Darkest Dark Theme von Genuitec, ein tolles und liebevoll gestaltetes Theme. Es ist jedoch sehr schade, dass Genuitec sich anscheinend dafür entschieden hat, nichts in Sachen Eclipse-Plattform beitragen zu wollen, sondern, soweit notwendig, Änderungen über Class-Loading-Hacks durchzuführen. Und das, obwohl die Firma von einer kommerziellen Eclipse-Distribution lebt. Dies ist gleich aus aus zweierlei Sicht schade: Genuitec verbessert damit nicht die Plattform, von der das Unternehmen lebt, und User haben immer dann Probleme, wenn sich die Plattform verändert und das Class Loading Hacking dann doch nicht mehr funktioniert. Zum Beispiel berichten Nutzer des Darkest Dark Theme häufiger von doppelten Einträgen in der Toolbar, wenn sie das Release wechseln. Oft trägt Darkest Dark Theme von Genuitec wegen der erwähnten Hacks die Schuld daran.

SWT und Windows – Patch des Monats

Separate Erwähnung verdient der Patch von Nikita Nemkin im SWT Windows Port. Nikita hat ca. 18 000 Zeilen Code gelöscht, indem er die Unterstützung für das von Microsoft und Oracle Java schon seit Jahren nicht mehr unterstützte Windows XP entfernte. Nach relativ kurzer Diskussion im Eclipse PMC wurde beschlossen, die Unterstützung von Windows XP auch für die Eclipse IDE offiziell nicht mehr zu gewährleisten. Windows-Benutzer profitieren dadurch von einer kleineren, damit besser wartbaren und möglicherweise auch schnelleren Codebasis, da viele Checks des Betriebssystems weggefallen sind. SWT-Entwickler können damit die Codebasis des SWT für Windows schneller und einfacher weiterentwickeln. Aus einer Konversation mit Nikita weiß der Autor, dass dieser noch viele grundlegende Verbesserungen für das SWT für Windows geplant hat. Das lässt doch auf ein noch besseres Standard Widget Toolkit in der Zukunft hoffen.

Alles gleichzeitig machen

Während viele an einer hübschen Eclipse IDE arbeiten, befasst sich Mickael Istria von Red Hat mit der grundlegenden Performance der Entwicklungsumgebung. Für Eclipse 4.8 hat er die Eclipse Builder parallelisierbar gemacht, d.h. unterschiedliche Tools können jetzt parallel Code umwandeln. So könnte das Spring Tooling beispielsweise Spring Beans lesen und entsprechende Marker schreiben, der Java-Compiler den Java Sourcecode umsetzen und XML-Validatoren könnten die schnöden XML-Dateien überprüfen – gleichzeitig.

Das Ganze ist noch in einer frühen Phase, da nun auch die Builder angepasst werden müssen. Zurzeit holen sich die meisten (z.B. der Java Builder) einen sogenannten Workspace Lock und laufen somit allein. Aber die Hoffnung ist, dass sich das in Zukunft ändert, da damit der Build-Prozess in Eclipse dann sehr viel schneller werden würde.

Eclipse Photon in den Startlöchern

Wie schon in einem vorherigen Teil der Kolumne angedeutet, hat sich das Eclipse-Projekt entschlossen, häufiger Releases herauszugeben. Das Planungskommittee des Eclipse-Release hat nun offiziell beschlossen, alle 13 Wochen (d.h. alle 3 Monate) ein neues Release herauszubringen. Nach Eclipse 4.8 (Photon) im Juni 2018 wird es also schneller vorangehen.

Das sind natürlich tolle Nachrichten für alle Nutzer der Eclipse IDE, die damit immer die neuesten Features in einem offiziellen Release zur Verfügung gestellt bekommen. Aber auch Kunden der Eclipse RCP, die die Eclipse-Plattform für ihre hauseigenen Applikationen nutzen, können sich freuen, da sie jetzt viel leichter von Verbesserungen oder selbst beigesteuerten Patches profitieren.

Fazit: Die Mühle dreht sich immer schneller

Die Eclipse-Entwickler schrauben auch weiter am Framework, das SWT wird weiterentwickelt und von Altlasten befreit. Zusätzlich gibt es bald alle drei Monate eine neue Version der Eclipse IDE und des damit verbundenen Frameworks. Gute Nachrichten für die Nutzer der Eclipse IDE und auch für Kunden der Eclipse Rich Client Platform.

Verwandte Themen:

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
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Lagebericht Eclipse-IDE: Neuigkeiten aus dem Eclipse-Projekt und von außerhalb"

avatar
400
  Subscribe  
Benachrichtige mich zu:
TestP
Gast

Schöner Lagebericht, weiter so. 🙂

MfG