JavaFX meets Eclipse: "Ungeahnte Dimensionen für heutige Entwickler"

EM: Mit e(fx)clipse hast du eine eigene JavaFX-Integration für Eclipse geschaffen. Wie sieht der momentane Entwicklungsstand des Projekts aus?

Schindl: Im Sommer 2011 habe ich begonnen, mich mit JavaFX auseinanderzusetzen und sehr schnell bemerkt, dass für eine IDE zwei wichtige Dinge benötigt werden: ein guter Java-Editor und ein CSS-Editor, der die JavaFX Extensions erkennt. Exzellente Java-Editoren findet man in allen modernen IDEs, egal, ob NetBeans, Eclipse oder IntelliJ. Auf der Suche nach JavaFX-CSS-Support bin ich aber bei allen IDEs auf ein Art Vakuum gestoßen. Der Zufall wollte es, dass ich mich schon immer mit Xtext beschäftigen wollte, um zu verstehen, warum es von so vielen so cool gefunden wird. Als ich mir dann überlegte, dass CSS nichts anderes ist als eine DSL, konkret eine, um Dinge zu stylen, war klar, was ich an den kommenden Abenden machen würde. Ich beschloss, das JavaFX-CSS-Vakuum zu schließen und veröffentlichte recht schnell die erste Version meines Xtext-basierten JavaFX-CSS-Editors auf meinem Blog und auf GitHub. Aus dieser Keimzelle hat sich dann die heutige e(fx)clipse Toolsuite entwickelt, die folgende Komponenten beinhaltet: Erstens einen CSS-Editor mit einigen herausragenden Eigenschaften für intelligente Autovervollständigung und Javadoc-ähnlicher Dokumentation, die ich von keinem anderen CSS-Editor kenne.

Zweitens einen FXML-Editor: FXML ist eine XML-basierte UI-Sprache, der aber keine XSD- oder DTD-Definition zugrunde liegt, sondern die vollständig in Java-Klassen spezifiziert wird. In Wahrheit ist FXML nur eine Serialisierungsvorschrift für einen Java-Object-Graphen. Hierfür bieten wir Autovervollständigung u.v.m.

Drittens einen Build-Editor: JavaFX liefert spezielle Ant-Tasks mit, die es dem Entwickler erlauben, Anwendungen z. B. für den Apple Desktop App Store zu verpacken. Wir bieten in unserem Tooling einen Editor, um den Produktexport sehr einfach zu gestalten und zu konfigurieren.

Viertens einen FXGraph: FXML ist an manchen Stellen sehr kryptisch und an anderen durch die Natur von XML sehr „noisy“. Um dem Entwickler eine komfortablere Art der deklarativen Oberflächenerstellung zu ermöglichen, haben wir die JSON-ähnliche Definitionssprache FXGraph entwickelt, die die FXML-Defizite vor dem Entwickler verbirgt, aber zur Laufzeit ohne weitere Bibliotheken auskommt (aus unserer DSL entsteht eigentlich wiederum FXML) und mit anderen Tools wie z. B. SceneBuilder zusammenarbeiten kann.

Fünftens eine Live-Preview: Für FXML und FXGraph bieten wir eine so genannte Live-Preview, mit der die Entwickler Änderungen in der Oberflächendefinition sofort sehen, ohne die wirkliche Anwendung separat starten zu müssen.

Die Grundfunktionalität ist nun schon seit einiger Zeit vorhanden und gefestigt, wir arbeiten aktuell an der Verfeinerung, um den Entwicklern ein noch angenehmeres Arbeitsumfeld zu ermöglichen. Darunter fallen Dinge wie Refactor-Rename-Support, verbesserte CSS-Validierung und Autovervollständigung, aber auch verbesserte Projekt-Wizards u.v.m.

EM: Wie siehst du die Zukunft von SWT?

Schindl: Zwiespältig. Erst einmal werden sowohl SWT als auch Swing erhalten bleiben, nur neue Features darf man sich hier kaum bis gar nicht mehr erwarten.

Das Investment in Dinge wie Eclipse IDE, NetBeans und auf deren Rich-Client-Plattformen ist so groß, dass diese noch lange weitergepflegt werden. Wie eingangs aber schon erwähnt, würde ich, wenn ich im Jahr 2013 eine RCP-Anwendung schreiben müsste, genau abwägen, ob nicht JavaFX die bessere Alternative ist.

Es kann natürlich immer noch Gründe für SWT geben, z. B. wenn man RAP verwenden will, aber auch im JavaFX-Umfeld werden Dinge wie Open Dolphin entwickelt. Obwohl unsere Firma stark auf JavaFX setzt, betreuen und entwickeln wir immer noch SWT-Anwendungen, wenn es die bessere Wahl für die konkrete Problemstellung ist.

Mit JavaFX für e4 von e(fx)clipse kombiniert man eine moderne Applikationsplattform mit einer modernen Oberflächentechnologie und begibt sich dennoch nicht in eine kommerzielle Abhängigkeit, weil alle Teile unter Open-Source-Lizenzen stehen und als Grundbestandteile von großen Frameworks (Eclipse IDE) oder Produktstrategien (JavaFX bei Oracle und Teil des OpenJDK) verfügbar sind.

EM: Vielen Dank für dieses Gespräch!

Tom Schindl ist Gründer und Mitbesitzer von BestSolution.at, einem auf Java- und Eclipse-Technologien spezialisierten Entwicklungs- und Consulting-Unternehmen. Er ist Committer in verschiedenen Eclipse-Projekten und Mitglied des Architecture Councils von Eclipse.
Kommentare

Schreibe einen Kommentar

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