Die großen Entwicklungsumgebungen bzw. deren Benutzer liefern sich seit Jahren gerne die sogenannten „IDE Wars“. Meist getrieben von enthusiastischen Fans, werden Artikel wie „Why I switched from Eclipse to [IRGENDWAS]“ und wundern uns, warum so viele Entwickler die geliebte Eclipse IDE verlassen. Solche Eindrücke sind natürlich sehr subjektiv, und oft scheint es, als sei das wichtigste Feature von anderen Entwicklungsumgebungen, dass sie eben nicht die Eclipse IDE sind.
Nimmt man dann einmal allen Mut zusammen und probiert eine andere IDE aus, ist man manchmal überrascht, was bei der Konkurrenz an Features fehlt und wie langsam andere IDEs sein können. Aber wie sieht nun die Realität aus? Wer treibt und bindet die anderen Entwicklungsumgebungen in die Dunkelheit? Oder frei nach Herr der Ringe: Wer ist denn der Ringmeister der IDEs?

Nach dem eher politischen Inhalt des letzten Teils der Kolumne geht es diesmal wieder um die technischen Entwicklungen der Eclipse IDE. Die Arbeiten an der neuen Version 4.8 sind bereits in vollem Gange und es ist wichtig, dabei auf dem Laufenden zu bleiben. Das Eclipse-Projekt hat außerdem beschlossen, ab 2018 alle drei Monate ein neues Release mit allen Neuerungen zu veröffentlichen, die bis dahin entwickelt sind. Daraus folgt, dass die Leser dieser Kolumne in Zukunft immer nur noch ein paar Wochen warten müssen, um in den Genuss der hier beschriebenen Änderungen zu kommen.

Alle Augen richten sich momentan auf die Eclipse Foundation. Wichtige Schlüsselprojekte der Java-Community – allen voran Java EE – wurden in den letzten Wochen an Eclipse übergeben. Zeit für eine Bestandsaufnahme.

Das Versionsverwaltungssystem Git ist weiterhin auf dem Vormarsch. Natürlich gibt es noch Kunden, die Apache Subversion (SVN) oder Perforce einsetzen. Wenn man sie aber darauf anspricht, hat man das Gefühl, dass manche sich zumindest ein bisschen dafür schämen. Außerdem erfährt man im Kundengespräch, dass viele die Migration auf Git bereits planen. Da die Verwendung der Git Command Line nun aber nicht jedermanns Sache ist, geht es in dieser Ausgabe um eine gute Alternative: das Eclipse Git Tooling.

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.

Eclipse hat in Sachen Usability nicht gerade den besten Ruf. Zu Recht? In dieser Folge der Kolumne Lagebericht Eclipse-IDE zeigen Simon Scholz und Lars Vogel, wie die Benutzerfreundlichkeit in Eclipse Oxygen verbessert wird.

NatTable ist eine erweiterte, selbstgezeichnete Tabellenimplementierung, die auf dem Standard Widget Toolkit (SWT) von Eclipse basiert. Sie erfreut sich großer Beliebtheit, denn sie bietet viele Features an, die übliche Tabellenimplementierungen nicht aufweisen. NatTable ist nicht weniger als die featurereichste Tabellenimplementierung für Java-User-Interfaces, die uns bekannt ist.

Oft werden in Eclipse so genannte Texteditoren verwendet, d. h. Editoren, die den Quelltext direkt anzeigen, aber durch Syntax-Highlighting oder Code Completion die Arbeit erleichtern. Traditionell war das Erstellen von neuen oder eigenen Editoren in Eclipse relativ kompliziert. Die Eclipse-Plattform hatte eigentlich nur die Möglichkeit geboten, in existierenden Editoren zusätzliche Klasse zu registrieren, die neue Textbereiche als Hyperlinks identifizieren. Viele Projekte haben daher eigene Frameworks entwickelt, um Editoren erweiterbar zu machen. Projekte wie Eclipse WTP mit den Source-Editoren für XML oder das Mylyn-Projekt für Wiki-Sprachen wie AsciiDoc haben hier gute Lösungen für isolierte Probleme geschaffen.

Neben dem klassischen hellen Styling gibt es inzwischen auch ein Dark Theme für Eclipse-IDE, das wir uns in der heutigen Kolumne einmal anschauen wollen. Außerdem zeigen wir, wie sich Buttons und Widgets individualisieren lassen.

Diesmal geht es in unserer Kolumne um die optimale Verwendung der Eclipse IDE. Natürlich hat jeder seine eigenen kleinen Tricks, aber ein paar Funktionen sollte jeder Nutzer kennen, um mit Eclipse noch besser arbeiten zu können.

Eine IDE ist dazu da, die alltägliche Entwicklungsarbeit zu vereinfachen und zu beschleunigen. Doch nur wenige gehen noch einen Schritt weiter, indem sie eigene Erweiterungen für die Automatisierung spezieller Anforderungen schreiben. Um solche Plug-ins zu schreiben, greift man am besten auf den „Eclipse for Committer“ Download zurück. In diesem Paket ist schon alles enthalten, was man zum effizienten Entwickeln von Eclipse-Komponenten benötigt.

Seit Eclipse 4.6 Anfang Juni veröffentlicht wurde, können sich die Nutzer an der Schnelligkeit und Leichtgewichtigkeit der IDE erfreuen. Aber beim Eclipse-Projekt ruht man sich natürlich nicht aus: Diesmal geben wir einen ganz kurzen Überblick über die Keyfeatures von Eclipse 4.6 und blicken anschließend darauf, was die Eclipse-Plattform für Version 4.7 in Planung hat.

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?

In ihrer Kolumne „Lagebericht Eclipse-IDE“ geben Lars Vogel und Simon Scholz Einblicke in die aktuellen Arbeiten an der Eclipse-Plattform. Wir beginnen mit einem Blick auf die „dunklen Jahre der IDE“, bevor wir uns mit 6 Highlights in Eclipse Neon auf die Sonnenseite des aktuellen Eclipse 4.6 begeben, auf der es viele nützliche Tricks zu entdecken gibt.