Interview mit Johan Vos zum JavaFX 14 Release

JavaFX 14: „Es gibt keine Gründe mehr, eine ältere Version von JavaFX zu verwenden, wenn man im Mobile-Umfeld unterwegs ist“

Dominik Mohilo

Johan Vos

Wie der „große Bruder“ Java, hält auch JavaFX 14 diesmal wieder seine neue Release-Kadenz ein. Pünktlich zur Veröffentlichung der neuesten FX-Version, sprachen wir mit Johan Vos, Co-Lead von OpenJFX, Java Champion und Project Lead von OpenJDK Mobile, über die Neuerungen in JavaFX 14. Im ausführlichen Interview erklärt er zudem, welche Probleme bei der Zusammenarbeit zwischen JavaFX und der GraalVM aufgetreten sind und wie diese gelöst wurden. Und auch einen kleinen Ausblick darauf, was die Nutzer in JavaFX 15 erwarten wird, konnte unser Experte bereits geben.

JAXenter: JavaFX 14 / OpenJFX 14 wurde gerade veröffentlicht, erneut einen Monat vor Java 14. Wird man bei der Nutzung von JavaFX 14 dennoch direkt alle neuen Funktionen von Java 14 nutzen können, oder werden die Nutzer auf ein späteres Release warten müssen?

Johan Vos: Sobald Java 14 herauskommt, können Nutzer von JavaFX 14 die entsprechenden Features des neuen JDKs nutzen. Wir haben allerdings andererseits die Hürden, die neueste Version von JavaFX zu nutzen, mit Absicht klein gehalten. Soll heißen, wer mindestens Java 11 benutzt, der kann auch JavaFX 14 nutzen. Dies ist die Konsequenz aus zwei wichtigen Zielen in Sachen Design:

  • Wir wollen, dass Nutzer bereits am Veröffentlichungstag die neuesten Features nutzen können
  • Wir wollen User nicht zwingen, auf die neueste Version des JDKs umsteigen zu müssen

JAXenter: Welche neuen Features hat JavaFX 14 für die Nutzer im Gepäck? Gibt es besondere neue Funktionen?

Johan Vos: Unsere höchste Priorität gilt der Sicherstellung, dass die in Anwendungen und Bibliotheken genutzten JavaFX APIs auch auf modernen Infrastrukturen laufen. Um dies zu gewährleisten, bieten wir die Unterstützung für neue Tools und Librarys sowie für Änderungen in den Betriebssystemen, auf denen gearbeitet wird. In Bezug auf Linux gehört dazu etwa die Umstellung von GTK2 auf GTK3, während Apple einige interessante Änderungen in macOS Catalina eingeführt hat.

Wir stellen nicht nur sicher, dass die Nutzer möglichst die aktuellsten Versionen ihrer Betriebssysteme und Bibliotheken nutzen können, sondern unterstützen auch ältere Systeme.

Doch wir stellen nicht nur sicher, dass die Nutzer möglichst die aktuellsten Versionen ihrer Betriebssysteme und Bibliotheken nutzen können, sondern unterstützen auch ältere Systeme. Das ist bei jedem Release eine Herausforderung. Da wir die Codebasis des OpenJFX langfristig sauber halten wollen, denken wir weniger an kurzfristige Patches mit neuer oder verbesserter Low-Level-Funktionalität, als viel mehr an die richtige Herangehensweise, um eine langfristige Wartung zu ermöglichen.

Das Webkit und die dazugehörigen Librarys haben ein Upgrade bekommen für JavaFX 14 und der Code ist generell einem kleinen Frühjahrsputz unterzogen worden. In Sachen Bedienung wurden – basierend auf dem Feedback von (Library-)Entwicklern – eine Reihe von Bugfixes durchgeführt und einige Unklarheiten beseitigt.

Wichtig ist auch, dass es mit OpenJFX 14 nun möglich ist, die JavaFX-Plattform mit der GraalVM in statisch-verbundenen Umgebungen zu nutzen.

Es wurde zudem ein fehlendes API hinzugefügt, durch das die Bedienfunktionen Dritter die TableView individuell anpassen und erweitern können (JDK-8207957). Die neue Property tabSize wurde Text und TextFlow hinzugefügt (JDK-8130738) und in der WebView wird nun auch HTTP/2 unterstützt (JDK-8211308).

Java Whitepaper

Gratis-Dossier: Java 2020 – State of the Art

GraalVM, Spring Boot 2.2, Kubernetes, Domain-driven Design & Machine Learning sind einige der Themen, die Sie in unserem brandneuen Dossier 2020 wiederfinden werden!

JAXenter: Ihr als das Team hinter JavaFX 14 habt euch wieder stark auf die Nutzung von JavaFX im mobilen Bereich (iOS / Android) konzentriert. Was bringt JFX 14 in der Hinsicht für die Nutzer?

Johan Vos: Vor JavaFX 11 wurde die mobile Variante von JavaFX in einem separaten Repository entwickelt, die auf alten Snapshots basierte. Für die Entwicklung von JavaFX 11 on mobile haben wir einen sauberen Fork von OpenJFX benutzt und dann einige Teile hinzugefügt, die spezifisch für die Mobile-Entwicklung genutzt werden können. Mit jedem nachfolgenden Release wurde der Unterschied zwischen diesem Fork und dem Haupt-Repository geringer.

Mit JavaFX 14 haben wir die Integration mit dem nativen Windowing-System von Android neu geschrieben und der Code wurde direkt in OpenJFX eingefügt. Diese Arbeit und eine Reihe weiterer Verbesserungen (etwa WebKit für iOS) sind bereits Teil von OpenJFX und werden wohl in JavaFX 15 enthalten sein.

Für Entwickler bedeutet dieser Ansatz, dass sie im Mobile-Bereich auf dem gleichen Stand wie im Desktopumfeld sind: Die gleichen APIs, die auf dem Desktop funktionieren, funktionieren auch für die Entwicklung mobiler Anwendugen. Es gibt also keine Gründe mehr, eine ältere Version von JavaFX zu verwenden, wenn man im Mobile-Umfeld unterwegs ist.

JavaFX 14 mit GraalVM: Probleme & Lösungen

JAXenter: Es gab ein paar Probleme in Bezug auf die Nutzung von JavaFX in Verbindung mit der GraalVM. Was genau funktionierte da nicht und welche Lösungen habt ihr gefunden?

Johan Vos: Zunächst muss festgestellt werden: die GraalVM beinhaltet eine Menge Komponenten. Die Hauptkomponente mit der wir arbeiten (und an der wir arbeiten), ist das Native-Image-Tool. Dieses kompiliert Java-Code “ahead of time” vor und kann ein statisch verbundenes Image erstellen.

Dadurch wurde ein fundamental anderes Herangehen nötig: In einem typischen Szenario hat ein Nutzer eine JavaFX-Anwendung und wenn er sie starten will, wird davon ausgegangen, dass die benötigten JAR-Dateien und Bibliotheken irgendwo vorhanden sind. Wenn man ein Image benutzt, das von Native Image erstellt wurde, ist dies nicht mehr nötig, da es bereits alle Bibliotheken enthält. Das bedeutet allerdings auch, dass wir anstelle von dynamischen Bibliotheken statische Bibliotheken für die JavaFX-Komponenten erstellen mussten.

Der Build kann mit der GraalVM ein wenig länger dauern, aber die Startzeit der Anwendung ist wesentlich schneller – das freut die Endnutzer.

Der AOT-Compiler der GraalVM versucht zudem so viel Arbeit wie möglich zur Build-Zeit zu erledigen. Daher kann der Build ein wenig länger dauern, aber die Startzeit der Anwendung ist wesentlich schneller. Das Building ist etwas, das nur der Entwickler machen muss, während die Startzeit der Anwendung auf Seiten des Nutzers zu Buche schlägt. Danke also an die GraalVM, die Endnutzer werden hierdurch sehr viel glücklicher werden, da die Anwendungen deutlich schneller starten.

Es gibt allerdings ein paar Einschränkungen, da nicht alles während der Build-Zeit kompiliert oder evaluiert werden kann oder sollte. Wir mussten daher ein paar Kniffe anwenden, um das Optimum an Balance zwischen Flexibilität und Performance zu erreichen.

Anstatt alles möglichst schnell auf der GraalVM lauffähig zu machen, haben wir uns die konzeptuellen Unterschiede zwischen der Verbindung mit geteilten Bibliotheken und statischen Bibliotheken angesehen. Gemeinsam mit den beteiligten Entwicklungsteams (von OpenJDK, GraalVM und natürlich OpenJFX) arbeiten wir daran, den besten Ansatz zu finden – ganz im Geiste von Java, denn Qualität und Wartbarkeit sind extrem wichtig. Wir wollen sicherstellen, dass sich die Top-Level-APIs für JavaFX mit verschiedenen Konfigurationen immer gleich verhalten. Dabei spielen natürlich auch mobile und embedded Plattformen eine Rolle.

Da GraalVM Native Image einiges an Konfiguration benötigt (Entwickler müssen bspw. eine Klassenliste erstellen, die für Reflexionen und JNI-Zugriffe in Frage kommen), haben wir Gluon Substrate entwickelt. Dieses Tool erledigt den Löwenanteil der Arbeit für den Entwickler und stellt Nutzern spezifischen Support für JavaFX zur Verfügung. Aktuell fügen wir dem noch weitere Funktionalität hinzu, beispielsweise die Unterstützung für Medien und die WebView. Einiges davon ist bereits in JavaFX 14 enthalten, das meiste für JavaFX 15 vorgesehen.

JAXenter: Gibt es irgendwelche anderen großen Bugs, die mit dem Release gefixt wurden?

Johan Vos: Über 50 Bugs wurden für JavaFX 14 gefixt, eine Liste gibt es in den Release Notes der neuen JavaFX-Version. Einige dieser Bugs waren seit langer Zeit bekannt und wurden nun gefixt, da einige Entwickler ihnen bei der Nutzung begegneten und Patches dafür schrieben. Manche Bugs entstanden wegen der Änderung in den Lower-Level-Betriebssystemen. Möglicherweise ist es nicht allzu überraschend, dass wir etliche Bugs fixen mussten, die durch die Ausführung von JavaFX-Anwendungen auf dem neuesten Apple-Betriebssystem (macOS 15 “Catalina”) eingeschleppt wurden.

JAXenter: Wie immer gab es einige Abhängigkeiten, die aktualisiert werden mussten. Was müssen Entwickler beachten, wenn sie auf JavaFX 14 umsteigen? Welche Dependencies wurden auf Stand gebracht?

Johan Vos: Wir selbst erzwingen mit diesem Update keinen Umstieg auf neue Abhängigkeiten. Allerdings haben einige der Betriebssysteme ihre Abhängigkeiten umgestellt. Daher haben wir sichergestellt, dass Entwickler nicht zusätzliche Packages installieren müssen.

Wie gewohnt konzentrieren sich die Sicherheitspatches in diesem Release hauptsächlich auf Web- und Medienkomponenten.

Sicherheit ist ein wichtiges Thema. Gab es irgendwelche Änderungen, die den Sicherheitsaspekt von JavaFX im Fokus hatten?

Johan Vos: Wie gewohnt konzentrieren sich die Sicherheitspatches in diesem Release hauptsächlich auf Web- und Medienkomponenten. Das liegt daran, da dies die gefährdetsten Bereiche sind, da sie externen Code beinhalten, der nicht immer (typ-)sicher ist. Die OpenJFX-Entwickler verfolgen die Entwicklungen in diesen Komponenten sorgfältig, und Sicherheitspatches werden bei Bedarf implementiert.

JAXenter: JavaFX agiert sozusagen als Testpilot für die Migration von Mercurial auf Git bzw. GitHub. Geht alles nach Plan, wird das JDK möglicherweise den gleichen Weg einschlagen. Wie geht es in dieser Hinsicht voran?

Johan Vos: Es existiert bereits ein GitHub Mirror für das OpenJDK und die Skara-Tools werden jeden Tag besser. Diese Werkzeuge werden gebraucht, um die hohe Qualität und die benötigten Prozesse für Projekte wie OpenJFX und OpenJDK zu erhalten. Das Skara-Team bei Oracle leistet hervorragende Arbeit dabei, die Migration von der veralteten internen OpenJDK-Infrastruktur auf das modernere GitHub möglichst reibungslos und effizient zu gestalten. Immer mehr Checks werden automatisiert, z.B. wird automatisch gecheckt, ob zwei Reviewers einen Pull Request abgesegnet haben, wenn dies als Voraussetzung eingestellt ist – gibt es keine zwei Reviews, kann der PR nicht gemergt werden. Zudem ist das Skara-Team sehr responsiv und offen für Ideen.

JAXenter: Welches ist dein Highlight des aktuellen JavaFX-Releases?

Ich bin wirklich glücklich, dass wir die Probleme mit macOS 15 so schnell beheben konnten.

Johan Vos: Ich bin wirklich glücklich, dass wir die Probleme mit macOS 15 so schnell beheben konnten. Als Apple diese Version veröffentlichte, gab es eine ganze Menge Dinge, die einfach nicht mehr liefen. Es ist an der Stelle nicht immer trivial, eine klare und offene Dokumentation zu bekommen. Dennoch haben viele Entwickler zusammen an einer Lösung gearbeitet und gerade bin ich einfach nur sehr happy, dass JavaFX 14 sehr gut auf Catalina läuft. Ich bin außerdem begeistert, dass die Unterschiede zwischen dem Code für mobile und eingebettete Geräte und dem herkömmlichen Mainstream-Code so gering sind.

JAXenter: Gibt es bereits Pläne für JavaFX 15?

Johan Vos: Tatsächlich gibt es die! Die Arbeit an JavaFX 15 hat bereits begonnen und das Team ist sehr aktiv. Wir neigen dazu, große Dinge möglichst früh im Entwicklungsprozess abzuarbeiten, sodass sie möglichst umfangreich getestet werden können. Wir werden mit JavaFX 15 aller Voraussicht nach die Unterstützung für mobile Anwendungsfälle weiter ausbauen. Der WebView-Code für iOS wurde von Grund auf neu gestaltet und auch an einer Überarbeitung des Codes für die Nutzung von Software-Tastaturen auf mobilen Geräten wird gearbeitet. Wir arbeiten außerdem daran, den JavaFX-Code mit den Neuentwicklungen des JDKs abzugleichen und die veralteten Finalisierungsmethoden aus der Codebasis zu entfernen.

Johan Vos started to work with Java in 1995. He was part of the Blackdown team, porting Java to Linux. His main focus is on end-to-end Java, combining back-end systems and mobile/embedded devices. He received a Duke Choice award in 2014 for his work on JavaFX on mobile. In 2015, he co-founded Gluon, which allows enterprises to create (mobile) Java Client applications leveraging their existing backend infrastructure. Gluon received a Duke Choice award in 2015. Johan is a Java Champion, a member of the BeJUG steering group, the Devoxx steering group and he is a JCP member. He is one of the lead authors of the Pro JavaFX books, the author of Quantum Computing for Java Developers, and he has been a speaker at numerous conferences on Java. He contributes to a number of projects, including OpenJFX, OpenJDK, GraalVM. He is also the project lead for OpenJDK Mobile and the co-lead for OpenJFX.

Mehr zum Thema:

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
Hinterlasse einen Kommentar

avatar
4000
1 Kommentar Themen
0 Themen Antworten
1 Follower
 
Kommentar, auf das am meisten reagiert wurde
Beliebtestes Kommentar Thema
1 Kommentatoren
Steven Letzte Kommentartoren
  Subscribe  
Benachrichtige mich zu:
Steven
Gast
Steven

Ich habe leider ein Problem mit javaFx14. Meine Komponten werden teilweise nicht auf anhieb gerendert.
Arbeite mit mehreren Tabs und zur Laufzeit füge ich die views in meine Hauptview. Beim ersten Laden werden diese einfach nict dargestellt. Keine Ahung, wie man das reproduzieren kann. Mir scheint, als hätten sie etwas am Eventmanagement geändert, was mir noch nicht so klar ist, was genau.