Suche
Hendrik Ebbers über den Stand der Dinge im JavaFX 8 UI-Kit

Mit Java 8 geht’s erst richtig los: "Für die Nutzung von JavaFX 8 gibt es keine Hürden mehr"

Hartmut Schlosser
Hendrik Ebbers

In seinem Artikel „JavaFX 8 – Was ist neu?“ beschreibt Hendrik Ebbers die Features, die uns mit JavaFX 8 zur Verfügung stehen. Hendrik bloggt auf seiner Webseite www.guigarage.com regelmäßig über Architekturansätze im Bereich JavaFX, ist Urheber verschiedener Open-Source-Projekte wie AquaFX oder DataFX und bereitet gerade das Buch „Mastering JavaFX 8 Controls“ vor, das voraussichtlich im Sommer erscheinen wird. Im Gespräch mit JAXenter gibt er eine persönliche Einschätzung ab, wie produktionstauglich JavaFX jetzt schon ist, wo JavaFX im Vergleich zu Swing steht und wie gut die Chancen sind, dass Java mit JavaFX eine Renaissance auf dem Desktop oder gar einen Boom auf Mobile/IoT-Devices erleben wird.

JAXenter: Du schreibst in deinem Artikel JavaFX 8 – Was ist neu?„, mit der Version 8 sei JavaFX bereit für den produktiven Einsatz. Woran machst du das fest?

Hendrik Ebbers: Ich kenne einige Firmen / Entwickler, die bereits erfolgreich Projekte mit JavaFX realisiert haben. Als Beispiel sei hier einmal das ETEO Board (http://www.eteoboard.de) genannt. Von all diesen Leuten habe ich im Gespräch größtenteils positives Feedback bezüglich JavaFX bekommen. Natürlich darf man nicht unter den Tisch kehren, dass es sicherlich auch mit JavaFX 8 noch ein paar kleinere Bugs bzw. offene Punkte geben wird. Aber welches Framework kann schon von sich behaupten, keine Bugs zu haben 😉  

JAXenter: Heißt das, dass JavaFX bereits Swing als UI-Kit ebenbürtig ist bzw. dieses schon überholt hat?  

Hendrik Ebbers: Das hängt ganz von der Betrachtungsweise und dem Einsatzszenario ab. In vielen Punkten ist JavaFX Swing meilenweit voraus: Features wie z.B. das Property API von JavaFX gibt es in der Form für Swing nicht. Auch Komponenten wie die WebView kann man für Swing nicht einfach realisieren. Dazu kommt, dass JavaFX eine deutlich modernere API besitzt und einfach von der Basis deutlich mehr Möglichkeiten zu bieten hat.

Man muss sich einfach mal überlegen, wann Swing realisiert wurde. Zu der Zeit hat niemand über Animationen oder Blur-Effekte in einem UI nachgedacht. Um diese für Swing zu programmieren benötigt es viel Knowhow und eine Menge an Code. Jeder, der schon einmal versucht hat, komplexe Effekte für Swing zu programmieren oder das Buch Filthy Rich Clients gelesen hat, weiß, wovon ich rede. Auf der anderen Seite sind aber mit der Zeit viele interessante Bibliotheken für Swing entstanden. Das JGoodies Forms Layout war für mich z.B. mehrere Jahre der Standard, wenn es um das Layout von Anwendungs-Masken ging.

Dazu kommt, dass Swing „System Look and Feels“ bietet, um Anwendungen auf dem jeweiligen OS nativ aussehen zu lassen. Dies gibt es für JavaFX bisher noch nicht. Von Haus aus beinhaltet es die beiden Cross-Plattform-Themes „Modena“ und „Caspian“. Auch wenn Modena ziemlich cool aussieht, erkennt man doch immer, dass es sich um eine JavaFX-Anwendung handelt, und es entsteht ein gewisser Bruch zwischen dem OS und der Anwendung.

Zum Glück gibt es hier aber bereits die ersten Ansätze seitens der Community. Mit AquaFX gibt es z.B. bereits ein Open Source Theme für JavaFX 8, welches das native Look and Feel von Mac OS nachahmt. Neben diesem Projekt gibt es bereits eine ganze Reihe an erstklassigen Open-Source-Projekten für JavaFX. Als Beispiele will ich hier einmal DataFX, OpenDolphin und ControlsFX aufführen. Und genau aus diesem Grund bin ich auch der Meinung, dass JavaFX in den Bereichen, in denen es vielleicht momentan Swing noch nicht überholt hat, innerhalb von kurzer Zeit nachziehen wird. Die Community rund um JavaFX ist extrem aktiv, und auch Oracle steuert weiterhin extrem viel dazu bei.     

JAXenter: JavaFX 8 bietet ja einige Hilfsmittel für die Migration von Swing nach JavaFX – beispielsweise SwingNode. Wie schätzt du den Aufwand ein, eine Swing-Anwendung nach JavaFX zu migrieren?

Hendrik Ebbers: Die genannten Hilfsmittel kann man sehr gut für eine fließende Migration nutzen. Das bedeutet, dass einzelne Bestandteile einer Swing-Anwendung nach und nach gegen JavaFX ausgetauscht werden.

Hierbei kann man sowohl den Ansatz wählen, JavaFX in Swing zu integrieren oder umgekehrt. Allerdings gibt es bei diesem Vorgehen einige Faktoren, die beachtet werden müssen: Wie bereits erwähnt, gibt es für JavaFX noch keine nativen Themes und auch keine Themes, die vom UI den Cross-Platform Look&Feels von Swing entsprechen. Daher wird man, solange man kein eigenes Theme entwickelt, immer einen Bruch im UI haben.

Darüber hinaus ist es sicherlich von der grundlegenden Architektur der Swing-Anwendung abhängig, wie kompliziert eine Migration wirklich wird. Ich selber kann hier aber auch nur theoretisches Wissen vorweisen, da mir die erste Migration einer größeren Anwendung noch bevor steht. Bisher habe ich nur ein paar Prototypen für Artikel, Vorträge und mein JavaFX-8-Buch erstellt.

[ header = Seite 2: JavaFX Boom, Lambdas und die Qualität des JavaFX Tooling ]

JAXenter: JavaFX ist als Teil von Java 8 sowohl im JDK als auch im JRE zu finden. Wie wird sich das deiner Meinung nach auf das Nutzerverhalten JavaFX gegenüber auswirken? Werden wir einen JavaFX-Boom erleben, der Java wieder jenseits der Server-Anwendungen interessant macht?

Hendrik Ebbers: Fest steht auf jeden Fall, dass es mit Java 8 nun erst richtig mit JavaFX losgehen wird. Dadurch, dass es nun fester Bestandteil des JDK und JRE ist, gibt es keine Hürde mehr, es zu nutzen. Sicherlich werden Entwickler in der nächsten Zeit eher JavaFX für die Erstellung von Desktop-Clients nutzen als Swing. Ob es einen JavaFX-Boom geben wird, kann heute wohl noch niemand sagen. Ich denke, dass JavaFX die grundlegenden Bausteine gesetzt hat. Ob Java auf dem Desktop wieder interessant wird, hängt aber sicherlich von vielen weiteren Faktoren ab. Durch App-Stores wurde es in den letzten Jahren wieder interessant, native Desktop-Apps zu entwickeln. Betriebssysteme wie Windows stehen hier ganz klar noch am Anfang, und es wird spannend, wie sich diese Technologien weiter entwickeln.

Hier wird sich in der nächsten Zeit dann zeigen, ob Java-Anwendungen auch ein Stück vom Kuchen ergattern können. Neben Desktop-Anwendungen ist aber sicher auch der Einsatz von JavaFX auf mobilen und Embedded Devices sehr interessant. Die Images für das Raspberry Pi werden mittlerweile mit Java ausgeliefert, und auch für Android / iOS gibt es erste Versionen von JavaFX.

Durch den mobilen Einsatz entstehen sehr interessante Synergieeffekte, sobald Entwickler für einen Desktop und Mobile-Client nur noch unterschiedliche Views erstellen müssen und den gesamten Rest einer Anwendung auf allen Devices nutzen können.

JAXenter: Du schreibst, dass JavaFX 8 bereits voll auf Lambdas abgestimmt sind. Was bedeutet das für Nutzer von Java 6,7?

Hendrik Ebbers: Die Frage würde ich nicht unbedingt auf JavaFX beziehen. Durch Java 8 sind Lambdas ein fester Bestandteil der Sprache, und jeder Entwickler sollte sich möglichst schnell damit auseinander setzten.

Bereits heute werden Lambdas in den ersten Frameworks genutzt, und es wird sicher nicht lange dauern, bis man sie flächendeckend vorfindet. Es würde ja auch heute kein Java-Entwickler mehr auf Generics verzichten.

Natürlich kann man bei der Arbeit mit JavaFX auch auf die Nutzung von Lambda-Ausdrücken verzichten und mit anonymen Klassen arbeiten. Da JavaFX aber bereits viele Functional Interfaces definiert, entsteht so schnell Boilerplate Code. Man kann das Ganze mit dem Stream API von Java 8 vergleichen: Theoretisch kann man auch hier mit anonymen Klassen arbeiten – aber wer will das schon?

JAXenter: Wie gut ist das aktuelle Tooling für JavaFX? Scene Builder, NetBeans, Eclipse, IntelliJ, andere Tools?

Hendrik Ebbers: Super! Mit dem Scene Builder und Scenic View gibt es direkt zwei sehr gute Tools zur Entwicklung von JavaFX-Anwendungen. Vor allem der Scene Builder wird immer besser- und schon heute will ich das Tool zur Dialog-Layout-Erstellung nicht mehr missen.

In der aktuellen Version sind die APIs des Scene Builders für die Integration in IDEs vorbereitet. Vor allem bei NetBeans passierte hier in den letzten Tagen einiges. Für Eclipse gibt es das e(fx)clipse-Projekt, das sich um die Integration von JavaFX in Eclipse kümmert.

Auch IntelliJ hat bereits eine JavaFX-Integration. Hier sei z.B. der CSS Editor genannt. Bei all den Tools und IDEs ist natürlich noch ganz klar Luft nach oben, und Scene Builder ist in keiner der IDEs zu 100% integriert. Allerdings kann man mit JavaFX auch problemlos ohne eine IDE- Integration arbeiten, da es sich um Plain Java handelt. Somit ist jedes Tool und jede Unterstützung ganz klar ein Vorteil gegenüber anderen UI Frameworks.

[ header = Seite 3: Highlights und Schwachstellen in JavaFX 8 ]

JAXenter: Was magst du am meisten an JavaFX 8?

Hendrik Ebbers: Oh, das ist eine schwierige Frage. Ich glaube, die coolste API von JavaFX ist die Property API. Jedes Mal, wenn ich nicht im JavaFX-Umfeld unterwegs bin, vermisse ich die Bindings.

Ein weiterer ganz klarer Pluspunkt ist die CSS-Integration. Anfangs stand ich dem Thema etwas skeptisch gegenüber. Sobald man aber die ersten Komponenten mit CSS gestyled hat, erkennt man den Mehrwert.

Als letztes würde ich noch FXML nennen. In der Kombination mit CSS kann man es wirklich schaffen, das UI, also Layout und Skin, komplett von der in Java implementierten Business-Logik zu trennen.

JAXenter: Wo liegen noch Schwachstellen, die du in folgenden Versionen gerne behoben sehen würdest?

Hendrik Ebbers: Ich denke, dass noch einige zusätzliche Komponenten ganz interessant wären. Da der Chef-Entwickler der JavaFX Controls aber auch für ControlsFX zuständig ist, denke ich, dass da einige in JavaFX 9 übernommen werden.

Dazu gibt es einige Klassen, die momentan noch in den private packages liegen und es zum Release von Java 8 nicht mehr geschafft haben, public zu werden. Vor allem, wenn man eigene Komponenten entwickelt, muss man hier ein paar Abstriche machen, wenn man nicht gegen private APIs arbeiten will.

Darüberhinaus fehlt mir an ein paar Stellen die Möglichkeit zur Erweiterung. So kann man zwar eigene CSS Properties erstellen und auch Parser für neue CSS values definieren, die bereits vorhandenen können aktuell aber nicht erweitert werden. Auch an der Unterstützung für Themes sollte noch weiter gearbeitet werden.

Auf der einen Seite sollte die Erstellung von System-Themes besser unterstützt werden. Zusätzlich ist es momentan nicht einfach möglich, Erweiterungen für Themes zu erstellen. Insgesamt bin ich aber mit der aktuellen JavaFX-Version sehr zufrieden.

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

Hendrik Ebbers Hendrik Ebbers hat mehrere Jahre Erfahrung in der Entwicklung von Java-Anwendungen. Sein Hauptinteresse liegt hierbei in den Bereichen JavaFX, Middleware und DevOps. Er ist aktuell als Senior-Java-Architekt bei der Materna GmbH tätig und leitet als aktives Mitglied der Java-Community die JUG Dortmund. Auf seiner Webseite www.guigarage.com bloggt er regelmäßig über Architekturansätze im Bereich JavaFX und zu seinen verschiedenen Open-Source-Projekten wie AquaFX oder DataFX.

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare

Schreibe einen Kommentar

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