Interview mit Johan Vos zum JavaFX 13 Release

OpenJFX 13: „Wir wollen das Qualitätslevel nicht drücken, nur um schneller neue Features zu bekommen“

Dominik Mohilo

Johan Vos

JavaFX 13 bzw. OpenJFX 13 ist bereits das zweite Major Release seit der Loslösung vom OpenJDK. Wir sprachen zu diesem Anlass mit Johan Vos, Co-Lead von OpenJFX, Java Champion und Project Lead von OpenJDK Mobile, über die wichtigsten Änderungen der neuen Version, die Vor- und Nachteile der halbjährlichen Release-Kadenz und die nächste Version, OpenJFX 14.

JAXenter: Hallo Johan und danke, dass du dir die Zeit genommen hast. OpenJFX 13 bzw. JavaFX hat gerade das Licht der Welt erblickt, was sind die Highlights des Releases?

Johan Vos: Grundsätzlich machen wir einfach weiter mit der Entwicklung, die wir mit der Etablierung des neuen Release-Zyklus’ begonnen haben. Konkret heißt das, dass wir Bugs fixen und an Features arbeiten. Wenn sie dann fertig für die Übernahme in eine neue Version sind, werden sie ausgeliefert.

JavaFX 13 enthält insgesamt 97 Bugfixes und Features in unterschiedlichen Komponenten des Projektes. Es wurden Kontroll- und Layout-Probleme behoben, WebView und die unterliegende Webkit-Implementierung wurden aktualisiert, das Build-System wurde verbessert und ein neues API erlaubt es nun, nativen Content, der von Anwendungen Dritter generiert wird, einfacher zu integrieren.

JAXenter: Welches dieser Features ist dein persönliches Highlight? Warum?

Das wichtigste Feature von JavaFX 13 ist der Support für das Rendern nativer Inhalte von Drittanbietern.

Johan Vos: Die möglicherweise wichtigste Änderung in JavaFX 13 hat die Kennziffer JDK-8167148 und fügt die Unterstützung für das Rendern nativer Inhalte von Drittanbietern hinzu. Dieses spezielle Feature wurde bereits seit sehr langer Zeit von etlichen JavaFX-Entwicklern gefordert. Ein Grund, warum es so lange gedauert hat, ist die Tatsache, dass es nicht ganz einfach umzusetzen ist, ohne die Kompatibilität für Cross-Plattform-Implementierungen der JavaFX APIs zu vernichten. Gewöhnlich sind wir eher geneigt, den generellen Richtlinien des OpenJDK zu folgen und möglichst minimalinvasiv zu handeln und die Rückwärtskompatibilität nicht zu gefährden. Auf der anderen Seite wäre es aber noch weniger wünschenswert, wenn Entwickler plattformabhängigen Code in die eigene Anwendung implementieren müssten.

So, wie wir es nun für JavaFX 13 umgesetzt haben, wird keine Rückwärtskompatibilität zerstört, das Risiko plattformspezifischer Verhaltensweisen ausgeschlossen und eine gute Basis geschaffen, auf deren Grundlage nun neue Funktionalität aufgebaut werden kann. Dieses Feature war Teil der Early Access Releases und es wurde ausgiebig in der Community und auf den Mailing-Listen diskutiert, insbesondere im GitHub Issue Tracker. Viele Entwickler haben bereits mit dem neuen API experimentier.

W-JAX 2019 Java-Dossier für Software-Architekten

Kostenlos: Java-Dossier für Software-Architekten 2019

Auf über 30 Seiten vermitteln Experten praktisches Know-how zu den neuen Valuetypes in Java 12, dem Einsatz von Service Meshes in Microservices-Projekten, der erfolgreichen Einführung von DevOps-Praktiken im Unternehmen und der nachhaltigen JavaScript-Entwicklung mit Angular und dem WebComponents-Standard.

 

JAXenter: Der neue Release-Plan orientiert sich stark am JDK, auch wenn JavaFX nicht mehr Teil des JDKs ist. Hat sich das in deinen Augen als sinnvoll herausgestellt, oder wäre eine etwas „freiere“ Veröffentlichungspolitik praktikabler?

Johan Vos: Der aktuelle Release-Plan erzeugt ein wenig Overhead, denn während wir Update-Releases für JavaFX 12 bereitstellen, werden gleichzeitig Early Access Releases für JavaFX 13 bereitgestellt und die Arbeiten an JavaFX 14 laufen ebenfalls schon zu diesem Zeitpunkt. Für Gluon ist es noch etwas komplizierter, da wir auch JavaFX 11 noch unterstützen und damit gleichzeitig an vier unterschiedlichen Versionen arbeiten.

Es gibt allerdings mittlerweile Tools, um vieles zu automatisieren, inklusive des Testings und Buildings. Für OpenJFX-Entwickler bedeutet diese Release-Kadenz weniger Stress, da sie praktisch nichts verlieren, wenn ihr Feature nicht die Deadline für das aktuellste Release einhalten kann: Spätestens sechs Monate später können sie es dann veröffentlichen.

Für JavaFX-Nutzer bedeutet der regelmäßige Zyklus reibungslosere Updates.

Für JavaFX-Entwickler (also jene, die die JavaFX APIs nutzen) bedeutet der regelmäßige Zyklus reibungslosere Updates. Wenn zwischen zwei Major-Versionen vier Jahre liegen, ist die Chance groß, dass Unternehmen eher nicht sofort auf das neue Release wechseln wollen, da die kosten für das Update sehr hoch sein können. Schnellere Releases machen es für Entwickler und Unternehmen einfacher, die neueste Version zu nutzen, ohne sich über allzu große Änderungen Gedanken machen zu müssen.

Vom Gesichtspunkt des Erwartungsmanagements her sollte betont werden, dass wir trotz der neuen Release-Kadenz nicht langsamer an Innovationen arbeiten, als zuvor. Wir wollen das Qualitätslevel nicht drücken, nur um schneller neue Features zu bekommen. Aber Entwickler verstehen, dass sich in sechs Monaten eben weniger große Änderungen und Features umsetzen lassen als in vier Jahren.

JAXenter: Ich erwähnte es bereits, JavaFX ist nicht mehr Teil des JDKs. Hat sich dies positiv oder negativ auf die Arbeit an dem Projekt ausgewirkt?

Johan Vos: Immer mehr Entwickler fühlen sich ganz wohl damit, dass JavaFX nun ein separater Download ist (via SDK oder Maven-Central-Artefakt). Die positiven Effekte dessen sind bereits sichtbar: Das oben besprochene Feature für natives Rendering wurde bereits sehr früh im Prozess für JavaFX 13 in die Early Access Builds integriert. So konnte entsprechend früh Feedback gesammelt werden. Die Downloadstatistiken zeigen, dass die EA-Builds sehr oft genutzt werden, auch das Feedback der Entwickler spricht da eine deutliche Sprache. Besonders über Maven Central werden sie bezogen. Für einen Entwickler ist es tatsächlich sehr einfach, die Version der JavaFX-Abhängigkeiten in der eigenen pom.xml oder build.gradle bspw. von 12.0.2 auf 13-ea+12 zu ändern. Es gibt keinen Grund für einen neuen manuellen Download, nur um ein bestimmtes Feature zu testen.

JAXenter: JavaFX 14 ist das nächste Release, welches wohl im Frühjahr des kommenden Jahres veröffentlicht werden wird. Gibt es bereits erste Ideen oder gar feste Planungen, was darin enthalten sein soll?

Wie das neue Release genau aussehen wird, das liegt in den Händen der OpenJFX-Entwickler.

Johan Vos: Wie das neue Release genau aussehen wird, das liegt in den Händen der OpenJFX-Entwickler. Bei Gluon hören wir vor allem auf unsere Kunden. Wenn die Kunden unserer LTS-Version von JavaFX 11 einen größeren Fokus auf einem bestimmten Bereich wünschen, dann arbeiten wir daran. Diese Kunden bezahlen letztendlich die Entwickler, die an OpenJFX arbeiten, und haben dementsprechend einen gewissen Einfluss auf die Roadmap.

Ich persönlich arbeite etwa an der Verbesserung des Build-Systems. Das Ziel ist hierbei eine bessere und umfangreichere Unterstützung für die Cross-Plattform-Entwicklung. Wir wollen an den Punkt gelangen, an dem wir 100 Prozent des OpenJFX-Codes nutzen können, um JavaFX für iOS-, Android- und eingebettete ARM-Geräte (32- und 64-bit) erstellen zu können. Wir wollen, dass JavaFX auf mehr Plattformen läuft als bisher. Im OpenJDK-Team wird gerade daran gearbeitet, Metal zu unterstützen. Wir sind gerade dabei herauszufinden, wie OpenJFX davon profitieren könnte.

JAXenter: Vielen Dank für das Interview, Johan!

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:

OpenJFX 13: „Durch die Entkopplung vom JDK bekommt JavaFX eine eigene Identität“

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

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: