Autor

Es soll hier keine Einführung in JavaFX gegeben werden – trotzdem soll das kleine „Hello World“ Beispiel ein gewisses Bauchgefühl vermitteln:

JavaFX-Anwendungen sind also prinzipiell nichts anderes als Java-Programme, die sich einer Control-Bibliothek bedienen und die Controls in Form eines Control-Baums hierarchisch zusammensetzen. In diesem Rahmen sind folgende Merkmale von Bedeutung:

• Transformationen und Animationen können in einfacher Weise definiert werden und dann auf jedem beliebigen Element des Control-Baums angewendet werden: rotiert man also beispielsweise einen bestimmten Container-Bereich, so werden alle darin enthaltenen Controls mit rotiert.
• Das Styling einer Komponente wird durch einen Stylesheet aufgeprägt (und kann dann natürlich noch individuell verändert werden). Das Look and Feel einer Anwendung kann also angepasst werden, ohne in die Codierung einsteigen zu müssen.
• Einige neue Komponenten vereinfachen die Programmierung – hier vor allem im Vergleich zum Vorgänger Java Swing: endlich gibt es eine saubere Art, HTML-Inhalte über ein Browser-Control („WebView“) in bestehende JavaFX-Programme einzubinden. Zwischen dem außenliegenden JavaFX-Programm und der HTML-Seite gibt es eine Schnittstelle – so dass beispielsweise Ereignisse der HTML-Seite im JavaFX verarbeitet werden können.
• Es gibt Bindingkonzepte, in denen Eigenschaften von Controls (z.B. der Text  eines Feldes) direkt an Eigenschaften aus der logischen Welt darunter gebunden werden können. Ändert sich die Eigenschaft in der logischen Welt, so ändert sich automatisch auch die Eigenschaft im Control – und andersherum.
• Neben dem programmierten Erstellen von Oberflächen (wie im obigen Beispiel) gibt es die Möglichkeit, Dialoge auch deklarativ („FXML“) zu definieren. Diese Deklaration ist dann wiederum Grundlage für am Markt verfügbare Editoren, über die man Dialoge ohne Programmierkenntnisse designen kann.

JavaFX-Programme sind auf den klassischen Desktop-Frontends lauffähig (Windows, Linux, MaxOS). Portierungen auf Android und iOS (also auf Tablet-Systeme) sind nicht offiziell vorhanden – diese Arbeit hat Oracle an die Java-Community übergeben. Es gibt hier lobenswerte Projekte und auch erste sichtbare Szenarien, die aus Sicht des Autors aber noch nicht über einen frühen Betastatus hinausgekommen sind. Darüber hinaus engagiert sich Oracle stark im Bereich von „embedded devices“ (z.B. Raspberry Pi). Hier steht JavaFX offiziell zur Verfügung.

Die Meinungen über den aktuellen inhaltlichen Status von JavaFX sind durchaus konträr – je nach Redner erhält man auf Konferenzen ein sehr positives, manchmal auch ein sehr negatives Bild. Recht unbestritten ist immerhin, dass JavaFX funktioniert und die beinhalteten Funktionen mit guter Performance und guter Stabilität zur Verfügung gestellt werden.

Woher kommen die unterschiedlichen Sichtweisen? Will man mit JavaFX eine größere Anwendung bauen, so stellen sich eine Reihe von Fragen, die über den eigentlichen Kern der UI-Verarbeitung hinausgehen. Beispiele hierfür sind:

• Wie groß ist der Control-Umfang und wie groß ist der Markt an Zusatzcontrols?
  Der Grundumfang an Controls von JavaFX ist „nett“ (und vergleichbar mit dem von Java Swing) aber nicht gerade berauschend. Gleichzeitig ist der Markt für Zusatzcontrols noch recht jung (Beispiel „JFXtras“). Controls können prinzipiell zwar einfach selbst erstellt werden, hierfür ist aber natürlich eine gehörige Expertise und ein entsprechender Aufwand notwendig.
• Wie wird PDF dargestellt, wie wird gedruckt?
  Auch hier gibt es natürlich erste Frameworks (Beispiel „JPedal“) oder Java Technologie (Java Print). Diese müssen aber erst einmal so aufgearbeitet werden, dass sie aus Sicht einer Anwendung einfach zu verwenden sind.
• Wie kommuniziert das JavaFX Programm mit dem Server, auf dem typischerweise ein Kernteil der Anwendung läuft?
  Da JavaFX auf Java beruht, kann man prinzipiell wieder „alles“ wählen: WebServices, REST-Calls, wer unbedingt will auch RMI (Remote Method Invocation).

Sie sehen: in all diesen Fragen geht es eigentlich nicht mehr um Innereien von JavaFX – sondern es geht darum, wie man sich um JavaFX ein produktives Umfeld aufbaut – um dann letztendlich auf produktive Weise größere Anwendungsprojekte zu stemmen. Und so sind auch die unterschiedlichen Sichtweisen auf JavaFX zu verstehen:

• Der Technologe sieht in JavaFX eine einfach programmierbare UI-Umgebung, an die er über die Programmierpsrache Java „mühelos“ Frameworks seiner Wahl anknüpfen kann. Die Flexibilität und Offenheit dieser Umgebung ist sehr groß. Deswegen auch das positive Bild.
• Der Anwendungsbauer sucht in JavaFX oft mehr als drinsteckt. Er erwartet eine Antwort auf Fragen wie die, die oben angeführt sind und ist dann enttäuscht, wenn die Antwort lautet, dass er sich um die Antworten bitte zunächst einmal selbst kümmern muss.

Diese unterschiedlichen Sichtweisen spiegeln auch das wider, was auf Sie zukommen wird, wenn Sie überlegen, JavaFX einzusetzen. Sie erhalten eine sehr gute UI-Technologie für Desktops, die Art und Weise, wie Sie diese nutzen, müssen Sie aber selbst definieren. Dies bedeutet nun nicht, dass Sie alle Räder selbst erfinden müssen – es gibt auch für JavaFX erste Anwendungsumgebungen (z.B. „CaptainCasa“ [1]), die die Brücke zwischen JavaFX und der Anwendungswelt schließen.
 

JavaFX steht natürlich in heftiger Konkurrenz zu anderen UI-Technologien – und der heftigste Wind bläst aus der HTML5-Richtung. Das auch berechtigte, wichtigste Argument, das Sie zu hören bekommen, wenn Sie ein JavaFX-Projekt starten wollen, ist: "JavaFX erfordert im Client eine Installation von Java – oder muss diese zumindest mitbringen. Der Aufwand für das Deployment beim Endbenutzer ist somit deutlich höher als bei HTML5-Anwendungen, bei denen man davon ausgeht, dass sie im Browser des Benutzers ablaufen („Zero Deployment“)".

Aus technologischer Sicht können Sie nun argumentieren:

• JavaFX basiert auf Java und ist im Vergleich zu HTML5/JavaScript wesentlich einfacher und effizienter in der Entwicklung und Wartung.
• JavaFX läuft außerhalb des Browsers in einer eigenen Umgebung – Sie müssen deswegen nicht bei jedem Browserwechel beim Endbenutzer fürchten, dass Ihre Anwendung nicht mehr läuft.
• JavaFX ist ein Java-Standard und deswegen langfristig verfügbar. Bei HTML5 hingegen gibt es eine deutlich stärkere Fluktuation von Frameworks.
• JavaFX kann wesentlich einfacher mit Subdevices (z.B. Scannern) in Kontakt gebracht werden.

All diese Argument helfen Ihnen in der Regel nicht, wenn es um Anwendungen geht, die in großer Zahl bei Ihnen unbekannten Endbenutzern ablaufen – hier schlägt die Deploymentfrage alle technologischen Diskussionen. Die Konsequenz für Sie muss somit sein: wählen Sie den Einsatzort mit Bedacht und kämpfen Sie diesbezüglich nicht gegen Windmühlen. Ein Shoppingsystem mit JavaFX zu bauen, mag eine technologisch hochinteressante Aufgabe sein, in der Realität wird aber kein anonymer Nutzer im Internet Java installieren, nur um Ihren Shop zum Laufen zu bringen, sondern er wird zum nächsten Shop gehen, der direkt im Browser läuft.

Positionierunsmöglichkeiten für JavaFX

Nicht alle Anwendungen sind aber „Anwendungen für Millionen anonyme Nutzer“ und somit gibt es dann auch genug Raum für den Einsatz von JavaFX. Szenarien, in denen JavaFX sinnvoll einsetzbar ist, kennzeichnen sich durch folgende Merkmale:

• Die Benutzer, die die JavaFX-Anwendung erhalten, sind keine anonymen Nutzern sondern „bekannt“. Beispiel: Sie bauen eine Anwendung für Sachbearbeiter eines Unternehmens. Der höhere Aufwand des Deployments ist somit kalkulierbar und in der Regel auch recht einfach in Zusammenarbeit mit der Systemadministration durchführbar.
• Die Anwendung, die Sie bauen sollte einen gewissen Umfang und auch einen gewissen Grad an UI-Komplexität haben. Andersherum gesagt: Um eine Adresserfassung zu programmieren, dazu braucht man nun wirklich nicht JavaFX sondern kann hier genauso gut zu HTML-Formularen greifen... Umgekehrt spielt JavaFX seine Effizienzvorteile in den komplexeren Szenarien erst richtig aus und passt somit umso besser.
• Die Anwendung, die Sie bauen, sollte eine gewisse Langlebigkeit haben und sich dadurch auch von vergleichsweise kurzlebigen Web-Anwendungen abheben.     

Dieses ist eines der gewichtigsten pro-JavaFX-Argumente: Wenn Sie heute eine komplexe Anwendung bauen (z.B. im Bereich der Warenwirtschaft), dann planen Sie 1-2 Jahre für deren Entwicklung, manchmal auch länger. In 1-2 Jahren erhält der Vertrieb somit die Anwendung und hofft dann, diese z.B. 5 Jahre lang verkaufen zu können. Der letzte Kunde bekommt also die Anwendung in 6-7 Jahre und will diese dann 10 Jahre lang nutzen.Sie sehen also: man ist mit bestimmten Anwendungen ganz schnell mit Lebenszyklen konfrontiert, die weit über 10 Jahre hinausgehen. Und genau bei diesen Anwendungen bietet sich JavaFX als langfristige, standardisierte Technologie an und steht damit durchaus in der Tradition seines Vorgängers Java Swing.

Überspitzt gesagt: wenn der Lebenszyklus des Kernteils Ihrer Anwendung deutlich länger ist als der Hype-Zyklus der derzeitigen HTML5-Frameworks, dann ist JavaFX eine gute Option! In meinem persönlichen Umfeld sind diese Merkmale bei einer Reihe von klassischen Unternehmensanwendungen vorhanden – von der Lagerlogistik, Produktionsdurchführung bis hin zu Controlling oder Personalanwendungen. Der Kernteil solcher Anwendungen ist weiterhin geprägt durch Sachbearbeiterbedienung mit entsprechend hohen Ansprüchen an Ergonomie, Performance und Langzeitstabilität. Hier passt JavaFX.

JavaFX ist da – es ist Bestandteil des Java-Standards. Die UI-Technologie ist gut – muss aber für den Einsatz in Projekten jeweils in die entsprechende Umgebung eingepasst werden. JavaFX richtet sich derzeit an Desktop-Szenarien für anspruchsvolle Anwendungen. Das Deployment von JavaFX muss im Rahmen der Szenarienwahl betrachtet werden. In einer Architektur rund um JavaFX muss immer auch HTML5 eine Rolle spielen. Dies gilt einerseits für den Einsatz der Anwendung für viele, anonyme Endnutzer, bei denen Zero Deployment ein Muss ist. Und es gilt für Szenarien, in denen JavaFX technologisch noch nicht zur Verfügung steht (Tablet, Mobile Devices)(Anmerkung: der Einsatz von JavaFX für embedded Devices ist möglich, wurde in diesem Artikel aber nicht erörtert).