Suche
Neues aus dem Land der Sonnenfinsternis

Eclipse Weekly Special: Wie Eclipse Two die Desktop-IDE neu definiert [Doug Schaefer im Interview]

Dominik Mohilo

©Shutterstock.com / solarseven

In der letzten Ausgabe von Eclipse Weekly haben wir ausführlich über Eclipse Two, den neuen Ansatz für die Eclipse IDE, berichtet. Das Projekt hat mittlerweile einige Aufmerksamkeit erregt und wird heiß diskutiert. Wir haben uns mit Doug Schaefer, dem Initiator von Eclipse Two, darüber unterhalten, warum Eclipse Two keine Web-IDE ist und wodurch es sich von Eclipse Che bzw. Orion unterscheidet.

JAXenter: Hallo Doug und danke, dass Du dir die Zeit genommen hast. Du bist ein Veteran in der Eclipse-Community und Project-Lead der C/C++ Development Tools (CDT). Daher vielleicht zunächst aus der Perspektive des C/C++-Entwicklers: Welche Vorteile hat die Eclipse IDE gegenüber anderen Entwicklungsumgebungen?

Doug Schaefer: Neben den großartigen Features, die wir mit den CDT anbieten und bei denen andere IDEs bislang hinterherhängen (etwa Rich Content Assist und die Source Navigation), ist es vor allem das Ökosystem aus zahlreichen Plug-ins, das Eclipse zur Verfügung stellt, durch das sie sich als populäre IDE für C/C++-Entwickler auszeichnet. Vor allem die Integration eines guten Ressourcenmanagements ist wichtig und Plug-ins wie EGit und das Subversion-Plug-in bieten genau das.

C/C++-Entwickler arbeiten oft auch mit anderen Sprachen, das gilt besonders für die Abstecher in das Internet of Things. Die Möglichkeit, in Eclipse mit mehreren Sprachen sowohl serverseitig als auch an dem eingebetteten Teil eines IoT-Systems arbeiten zu können – und das unter Verwendung der gleichen Tools –, erlaubt es Entwicklern, einfacher am gesamten Stack zu arbeiten.

Es ist in Eclipse auch kein Problem für Entwickler, ihr System mit Domänen-spezifischen Sprachen (DSLs) zu erweitern, dank Xtext kann man so vom vollen Funktionsumfang der IDE Gebrauch machen. Der Tatsache, dass die Systeme, mit denen C/C++-Entwickler arbeiten, dazu neigen, sehr komplex zu sein, hat dafür gesorgt, dass sie eine der ersten Communities waren, die die Modellierung eingeführt hat. Eclipse hat auch hierfür zahlreiche und reichhaltige Plug-ins.

JavaFX sah vielversprechend aus. Die Java-Community hat sich aber ganz offenkundig nicht dafür als Desktop-GUI-Framework der Zukunft entschieden.

Eclipse ist, das braucht eigentlich gar nicht erwähnt zu werden, auch perfekt dazu geeignet, eigene Plug-ins zu erstellen. Gerade C/C++-Entwickler können so ihre IDE bestens auf die jeweiligen Ansprüche und Umgebungen einstellen und entsprechende Features einfach hinzufügen. Mit anderen Entwicklungsumgebungen wäre das sehr viel umständlicher, besonders mit denen, die ihre APIs nicht veröffentlichen.

Dieses reichhaltige Ökosystem resultiert aus dem Vorhandensein einer starken, offenen Community, die nicht einem einzelnen, kommerziellen Anbieter gehört. Dadurch kann jeder, der möchte, seine Ideen beitragen und die Entwicklungsumgebung erweitern.

JAXenter: In deinem Blog-Post kündigst du die aktive Arbeit an „Eclipse Two“ an, deren Ziel, das wurde klar kommuniziert, die Ablösung der „klassischen“ IDE sein soll. Weshalb ist dieser Schritt deiner Meinung nach notwendig?

Doug Schaefer: Naja, das Ziel ist eigentlich eher, einen möglichen Nachfolger zu entwickeln. Ob diese Arbeit dann Erfolg hat und unser Projekt als offizieller Nachfolger fungieren kann, entscheidet letzten Endes die Community.

Die Idee zu Eclipse Two hatte ihren Ursprung in einem Gedankenexperiment: Ich versuchte mir vorzustellen, wo Eclipse in fünf oder zehn Jahren stehen würde. In meinen Augen sind wir, sofern wir reichhaltige Visualisierungen nutzen wollen, durch das SWT stark eingeschränkt. JavaFX sah vielversprechend aus. Die Java-Community hat sich aber ganz offenkundig nicht dafür als Desktop-GUI-Framework der Zukunft entschieden. Daraufhin begann ich intensiv über die Zukunft von Java als Desktop Application Environment nachzudenken und ob es nicht andere Technologien gibt, die uns dies vielleicht ermöglichen könnten.

Für mich ist Eclipse Two keine Web-IDE

Dies führte mich zu Electron, das auch von den Editoren Visual Studio Code und Atom verwendet wird. Ich bin gespannt, ob wir es schaffen, eine vollständige IDE zu bauen, die auf den Kernkomponenten von Electron, also dem Chromium Browser und Node.js, basiert. Gleichzeitig soll es uns dabei helfen, die Art und Weise, wie wir Entwicklungsumgebungen nutzen, zu überdenken und vom klassischen Ansatz eines Desktop-Paradigmas wegzukommen, das in den 1990er Jahren das Fundament der „klassischen“ Eclipse IDE darstellte. Es ist immer recht interessant und spaßig darüber nachzudenken, was man anders machen würde, wenn man könnte – dies ist die Chance, genau dies in die Realität umzusetzen.

JAXenter: Welchen Vorteil hat es, Eclipse als Web-IDE, basierend auf Technologien wie Chromium und Node.js (Electron), aufzubauen?

Doug Schaefer: Tatsächlich ist Eclipse Two für mich keine Web-IDE. Mein Fokus liegt einfach darauf, die HTML DOM APIs als GUI-Framework für eine Desktop-IDE zu benutzen. Hierfür eignet sich Electron hervorragen, denn es bietet ein sehr gut definiertes Browser Environment, da es den Browser bereits beinhaltet. Auch eine native Environment-Integration ist, dank der Node.js APIs, bereits an Bord, was uns den Einsatz aller Bibliotheken des npm-Katalogs ermöglicht. Electron bietet uns also praktisch alles, was wir brauchen, um eine moderne UX anzubieten und gleichzeitig alle Tools und Services bereitzustellen, die Softwareentwickler erwarten.

Interessant ist dies auch wegen der recht großen Anzahl an Entwicklern, die mit diesen Technologien vertraut sind. Das größte Problem, das wir mit der „klassischen“ Eclipse IDE haben, ist es, Java-Entwickler zu finden, die auch mit der Workbench-Architektur von Eclipse vertraut sind. Das gilt insbesondere für die C/C++ Community. Web-Technologien sind im Gegensatz dazu weiter verbreitet und man kann sie sogar in eingebetteten Produkten mit HTML-getriebenen Oberflächen oder als Browser-basierte Visualisierung eingebetteter Systeme finden. Die Möglichkeit, aus einer so großen Community Mitarbeiter anzulocken, wird der Eclipse Community neues Leben einhauchen.

JAXenter: Durch das Language Server Protocol soll auch Eclipse Two polyglott werden. Deine Einschätzung: Ist das LSP die Zukunft der Sprachunterstützung in sämtlichen IDEs oder gibt es andere vielversprechende Technologien?

Doug Schaefer: Mit dem Language Server Protocol werden zum ersten Mal wirklich sämtliche Entwickler dazu aufgefordert, an der Entwicklung teilzunehmen. Microsoft ist sehr offen für Erweiterungen des Protokolls in Form von verschiedenen Language Server Providern und Client Frontends und hat die Notwendigkeit für diese Offenheit erkannt. Dies macht das ganze sehr interessant aus der Perspektive der Eclipse C/C++ Development Tools. Besagte Offenheit wird ein Ökosystem aus Language Servern hervorrufen, das wir dann – nicht nur mit Eclipse Two, sondern auch mit der „klassischen“ Eclipse IDE – vorteilhaft werden einsetzen können.

JAXenter: Dein Projekt „Eclipse Two“ wird mit „The real next-generation Eclipse IDE based on Electron“ beworben. Das erinnert sehr an Eclipse Che: Worin unterscheidet sich Eclipse Two von Eclipse Che bzw. Eclipse Orion, die ebenfalls auf einen Web-Editor setzen?

Doug Schaefer: Der Hauptunterschied ist, dass Eclipse Two keine Server-Komponente hat. Alles ist lokal auf dem eigenen System, wie es auch bei der „klassischen“ Eclipse IDE der Fall ist. Für die Nutzung ist es nicht nötig, Zeit von Cloud-Service-Providern zu mieten, einen eigenen Server zu unterhalten oder Docker zu installieren. Es ist eine herkömmliche Desktop-Anwendung, die eben mit Web-Frontend-Technologien und JavaScript-Bibliotheken erstellt wurde, welche auf das lokale System sowie auf verteilte Server zugreifen können.

Ich verstehe die Notwendigkeit von Server-basierten Architekturen für Entwicklungsumgebungen, glaube aber nicht, dass sie irgendwann Mainstream sein werden. Aus dem einen oder anderen Grund fühlen sich Entwickler eben einfach sicherer, wenn sie den Code, mit dem sie arbeiten, auf den Festplatten ihrer lokalen Maschinen liegen haben. Ich denke, dass genau dies in der überblickbaren Zukunft Mainstream bleiben wird. Deshalb sollten wir sicherstellen, für diese Entwickler die beste Entwicklungsumgebung zu erschaffen, die mit aktuellen Technologien für Desktop-Anwendungen möglich ist.

JAXenter: In deinem Blog-Post sprichst du das feste Vorhaben an, Eclipse Two mit der Eclipse Community gemeinsam zu entwickeln. Wie hoch schätzt du die Erfolgsaussichten darauf ein, dass Eclipse Two ein offizielles Eclipse-Projekt wird und ggf. sogar die „klassische“ Eclipse IDE ablösen kann?

Doug Schaefer: Nur durch die Hilfe der Eclipse Community wird Eclipse Two jemals bereit sein, von der breiten Masse genutzt zu werden. Ich allein habe nicht die Ressourcen, um dies zu realisieren, genau so wenig wie mein Arbeitgeber. Entweder wird dies ein Eclipse-Projekt, oder ich werde das Projekt ad acta legen.

Das größte Problem, das wir mit der „klassischen“ Eclipse IDE haben, ist es, Java-Entwickler zu finden, die auch mit der Workbench-Architektur von Eclipse vertraut sind.

Derzeit sieht es allerdings gut aus: Es gibt viele Leute, die Interesse zeigen, Fragen stellen und Vorschläge für Eclipse Two machen. Es macht wirklich Spaß, mit dieser Technologie zu arbeiten, und es ist sehr spannend. Daher denke ich, dass sich um Eclipse Two – oder ein sehr ähnliches Projekt – sehr schnell eine Community etablieren wird.

JAXenter: Die Eclipse IDE ist eine große Plattform für zahlreiche Toolings und Anwendungsfälle, ist Eclipse Two kompatibel mit der großen Masse an Plug-ins und Zusatztools?

Doug Schaefer: Dinge wie das Language Server Protocol sind ein Weg, Komponenten der „klassischen“ Eclipse IDE wiederzuverwenden. Red Hat arbeitet daran, einen Java Language Server zu erstellen, der auf den Java Development Tools basiert. Auch die CDT Community ist dabei, einen LSP-Provider für C/C++ zu bauen. Diese beiden Projekte werden ganz sicher von Eclipse Two verwendet werden. Es gibt ein node-Modul, mit dem man eine JVM in Betrieb nehmen kann und ein Interface zu ihr zur Verfügung stellt. Das könnte man nutzen, um Zugang zu anderen Eclipse Plug-ins zu erhalten. Eclipse RAP wird von einigen als potentieller Mechanismus der Wahl angesehen, um das User Interface von Eclipse Plug-ins wiederzuverwenden.

Dies sind allerdings nur einige mögliche Wege, und es wird schwer sein, diese Integrationen klar und mit hoher Nutzerfreundlichkeit umzusetzen. Ich bin zwar nicht sicher, wie viel Wiederverwendung möglich ist, erwarte aber, dass mich die Community in Bezug darauf überrascht.

JAXenter: Wie lange wird es in deinen Augen (etwa) dauern, bis Eclipse Two für den Einsatz als Entwicklungsumgebung für Projekte bereit ist?

Doug Schaefer: Das liegt natürlich an der Community. Für mich umfasst die erste Phase, Self-Hosted Development zu unterstützen, anschließend werde ich Eclipse Two als Eclipse-Projekt vorschlagen. Wir werden dann sehen müssen, wie es in der Gemeinschaft ankommt und ob es in Schwung kommt.

Die Planung bezog sich, wie bereits erwähnt, auf eine Zeitspanne von fünf bis zehn Jahren von jetzt an. Meine Hoffnung ist es, dass die IDE in etwa fünf Jahren bereit zum Einsatz ist. Natürlich ist dieses Ziel sehr viel früher möglich, wenn die Community das Projekt annimmt und sich richtig reinkniet. Auch über die nächsten Jahre hinweg wird die „klassische“ Eclipse IDE noch ein probates Mittel sein und sogar darüber hinaus. Wir werden natürlich dafür sorgen, dass sie sich weiterhin möglichst reibungslos von den Anbietern und Nutzern verwenden lässt, die sich in ihrer täglichen Arbeit auf sie verlassen.

JAXenter: Vielen Dank für das Interview!

Kaum eine Community ist aktiver und innovativer als die der Eclipse IDE. JAXenter hat das Ohr am Puls der Entwicklungsumgebung und berichtet wöchentlich über die neuesten Entwicklungen und die spannendsten Geschichten rund um Eclipse.

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare
  1. Harald Wellmann2017-01-14 18:07:33

    Das größte Problem, das Eclipse Two haben wird, ist es, Java-Entwickler zu finden, die freiwillig mit JavaScript und node.js arbeiten.

Schreibe einen Kommentar

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