JavaFX article, letter to the editor

Recently I sent a letter to the editor to the Javamagazin concerning the German JavaFX article "JavaFX 1.0 - Ein erster Eindruck" published in edition 2.09.

Liebe Redaktion,

der Artikel „JavaFX 1.0“ aus der Ausgabe 2.2009 wie auch schon sein Vorgänger aus 12.2008 haben mein Interesse geweckt. Gleich vorweg: Grundsätzlich teile ich die Begeisterung des Autors bzgl. JavaFX (JFX). Ich freue mich über das an JavaFX, was bis dato bereitgestellt wurde und freue mich auf die weitere Evolution. Dennoch sollte man das eine oder andere etwas kritischer betrachten. Der Artikel ist aber praktisch so wohlwollend geschrieben, er könnte auch von der Marketing-Abteilung von Sun Microsystems geschrieben worden sein. ;-)

JavaFX hat im Hause Sun Microsystems eine strategisch bedeutende Rolle eingenommen. Diese Feststellung des Autors ist vollkommen richtig. Ich vermisse allerdings ein Hinweise auf die doch weitreichenden Implikationen und Reibungspunkte, die damit verbunden sind. Der enorme Abzug von Ressourcen aus anderen Bereichen macht sich beim Fortschritt der jeweils anderen Aktivitäten bemerkbar. Was ist aus der Ankündigung geworden in kurzen Abständen Java-Hauptreleases bereitzustellen. Nach langer Unruhe und suboptimaler Kommunikation wurde nun erst kürzlich ein Mission Statement bzgl. Java 7 an die Öffentlichkeit getragen. Das allerdings erst schön sichtbar und publikumswirksam auf der Devoxx-Konferenz. Trotz der Stärkung des Clients sind in eben der vom Autor titulierten 500-Tage Phase Sun's Rich Client Urgesteine und führende Köpfe Hans Muller (auch Vater vom Swing Application Framework, JSR 296) und Chet Haase zu Adobe gewechselt. Wie passt das zusammen?

Ob Sun sich mit dem Release 1.0 einen großen Gefallen getan hat, so die These des Autors, sehe ich ambivalent. Sicherlich ein guter Marketing-Schachzug nun (endlich) mit etwas Greifbarem herauszukommen. Aber hat hier nicht auch das Marketing die Taktfrequenz bestimmt, genauso wie vor 18 Monaten bei der doch sehr überstürzten Ankündigung von JavaFX auf der JavaOne 2007? War es nicht jetzt das Marketing, dass auf eben dieser Devoxx 2008 die jedes Jahr praktizierten Sun-Keynotes publikumswirksam füllen wollte und ggf. deswegen JFX 1.0 kurz vorher bereitgestellt wurde? Rein technologisch hat sich Sun mit 1.0 für meine Begriffe keinen Gefallen getan. Zu viele Bugs, Ungereimtheiten und fehlende Features sind latent vorhanden, dazu im Laufe dieses Beitrags noch mehr. Andererseits: Insgesamt sehe ich doch Parallelen zwischen der Historie von Java selbst und nun JavaFX. Erst ab Versionen Java 1.1 und Java 1.2 wurde es tatsächlich produktiv nutzbar. Zwischen einem Preview- und einem finalen 1.0 Release unzählige Änderungen umsetzen ist eine Sache, die direkte Ankündigung, dass noch weitere schwergewichtige Änderungen folgen werden eine andere.

Laut Autor sei die Vermischung von Swing- und Java-2D mit JFX 1.0 deutlich besser gelungen.Das ist aber nur eine Seite. Sowohl Swing als auch Java-2D sind nicht neu, ganz im Gegenteil. Für mich ist vielmehr die entscheidende Frage, wie es mit der Vermischung JFX 1.0 mit der bereits existenten und genutzten Bestandstechnologie aussieht. OK, man kann Swing-Komponenten wrappen. Es bleibt aber weiterhin mehr als undurchsichtig, was JFX technologisch genau bezwecken will? Der Ankündigung JFX als Swing-Abstraktion anzubieten, sind kaum Taten gefolgt bzw.: sie sind inkonsistent. Vielmehr baut sich immer mehr eine gänzlich neue Client-Technologie auf. Schaut man mal genauer auf die von JFX generierten Objektgeflechte, wird es einem schwindelig. Swing-Komponenten und proprietäre FX-Komponenten, FXNodes, SGNodes und SGParents laufen einem da beispielsweise über den Weg – nur mit viel Wohlwollen kann ich hier ein schulbuchmäßiges Design ausmachen. Obwohl das Wrappen und der knotenbasierte Ansatz (doch nun wirklich nicht innovativ) in der Theorie gut klingen, wirkt in der Praxis das eine oder andere unter Zeitdruck “zusammengezimmert”. Die ganze Holprigkeit manifestiert sich beispielsweise in der Interoperabilität zwischen Bestandstechnologie und JavaFX. Der derzeit sauberste Weg eines Aufrufs einer FX-Anwendung über Java gelingt beispielsweise derzeit über Java's Scripting Engine. Das kann aber wohl doch nicht das Ende der Fahnenstange perfekter Interoperabilität sein?!

Bei der Erstellung der FX-Anwendung lassen sich insbesondere auch durch Wiederverwendung von existenten Komponenten in der Tat recht schnell brauchbare Ergebnisse liefern. Stimmt. Dies trifft aber grundsätzlich auf jedes Java-Projekt zu, in der hier diskutierten Zieldomäne beispielsweise auch auf das “Swing Application Framework”. Dem Binding-Feature von JavaFX ist dabei zurecht ein mindestens gleichgroßer Stellenwert einzuräumen. Schade, dass es JSR 295 nicht nach Java 7 schaffen wird. Ein Binding-Mechanismus für JavaFX ist auch dringend nötig: Eine munterer Sprachblumenstrauß innerhalb eines Artefakts wird einem “Designer”schwerlich zumutbar sein.

Die Feststellung die Sprache JavaFX sei nicht Java ist nicht überraschend, die Ableitung JavaFX sei eine domänenspezifische Sprache halte ich aber für irreführend und recht wohlwollend. Irgendwie ist dann doch plötzlich alles eine DSL. Nüchtern betrachtet: Nicht wenige sehen die Einführung einer gänzlich neuen Sprache sehr ambivalent. Warum muß alles neu sein? Hätte es nicht auch eine bereits bekannte, stabile, reife Sprache sein können?

Es stimmt schon, dass der Einstieg für kleinere Testanwendungen verhältnismäßig leicht ist. Wie weit das alles schon produktionsreif ist, bleibt fragwürdig. Sehr schnell stößt man auch auf interessante Erkenntnisse. Dies gilt beispielsweise für das funktionale, über das GUI angestoßene Testen solcher JFX-Anwendungen, was für mich als Commiter des FEST-Frameworks von besonderer Bedeutung ist. So sind die darunterliegenden Swing-Komponenten tatsächlich “versteckt und vergraben” und Oberflächen nur mit raffinierten Mechanismen funktional testbar. Auch hier wangt das Ziel der Interoperabilität ganz offensichtlich. Eine weitere Grenze ist das Tooling. Das eine Sprache, die noch „under construction“ ist, nicht sonderlich viele Unternehmen zwecks Bereitstellung von Werkzeugunterstützung anzieht, scheint offensichtlich. Der wesentliche Punkt dabei ist allerdings ein anderer: JFX ist bis dato eine proprietäre Angelegenheit von Sun Microsystems. Es fehlt ein JSR. Es wäre natürlich noch sauberer gewesen zunächst mal mit einer Spezifikation anzufangen oder nebenläufig eine zu schreiben (hervorragende Kommunikationsgrundlage!), insbesondere auch, um darin zu definieren, wohin die Reise eigentlich hingehen soll. Derzeit ist der JFX-Leistungsumfang kaum zu beurteilen, fehlt doch jedliche konkrete Definition der Zielsetzung. Von der (fehlenden) Anforderung zur “weich umrissenden” Zielgruppe: Traurigerweise sind konventionelle Java/Swing-Entwickler sicher nicht Bestandteil der Zielgruppe von Version 1.0, was man beispielsweise an den größeren Defiziten bei der Interoperabilität erkennt. Das ganze Drama spiegelt sich beispielsweise auch bei der aktuell einzigen, halbwegs soliden JFX-IDE wider: NetBeans 6.5. Hier wird fleißig unterschieden zwischen Java und JavaFX. Warum? Die ersten Fragen stellt sich ein Entwickler, wenn er vor der Entscheidung steht ein Java-Projekt zu erstellen, um dort FX-Artefakte zu hinterlegen. Oder soll er lieber den anderen Weg gehen: Ein JavaFX-Projekt aufmachen, und dann dort Java-Artefakte erstellen? Die Entscheidung, wie immer sie ausfällt, hat operative, nur halbwegs nachvollziehbare Konsequenzen, beispielsweise wie ein Artefakt ausgeführt werden kann. Für mich ein Schritt rückwärts auf der Reise der polyglotten Gemeinde.

Ob man den aktuellen Meilenstein 1.0 nennen muß oder nicht: Es ist noch viel Arbeit notwendig. Es mußte in den vom Autor angeführten 500 Tage sehr viel Grundlagenarbeit durchgeführt werden (hausgemacht. Nochmal die Frage: warum eine neue Sprache?), und der aktuelle Stand macht einen guten Eindruck. Natürlich füllt JavaFX eine Lücke bei reichhaltigen, auf Java basierenden Client-Anwendungen. Multimediale, mit Animationen versehene, deklarativ zu beschreibende Applikationen für Browser, Desktop und später auch für mobile Endgeräte, und allem voran das schöne Herausziehen der FX-Anwendungen aus dem Browser auf den Desktop, all das macht Lust auf mehr. Ob aber noch weitere 500 Tage reichen werden, um den enormen Vorsprung von Marktbegleitern wie Adobe aufzuholen, bleibt abzuwarten. Denn auch jetzt schon und auch ohne JavaFX lassen sich Frontend- und Backend-Technologien von Enterprise-Anwendungen sauber entkoppeln. Ich hoffe, die weitere Evolution von JavaFX gelingt und es wird keine Weiterentwicklung von anderen Technologien und Standards darunter leiden müssen.

Mit freundlichem Gruß
Michael Hüttermann