Expertencheck - Teil 1

JavaFX-Standortbestimmung: JavaFX 11, ein Rückblick und ein Sprung nach vorn

Gabriela Motroc

© Shutterstock / indiovetorepurodotcom

 

Mit JavaFX 11 ist eine neue Ära für das Java-UI-Toolkit angebrochen. Nach der Ausgliederung aus dem JDK stellt sich die Frage, welcher Zukunft JavaFX im Rahmen des OpenJFX-Projektes entgegenstrebt. Zeit für eine Standortbestimmung.

Nach der Veröffentlichung von JavaFX 11 ist es Zeit, etwas genauer auf den aktuellen Stand und die Zukunft des Projektes zu blicken. Dafür haben wir Johan Vos, Jonathan Giles, Dirk Lemmermann und Donald Smith eingeladen, um über die aktuellen Entwicklungen zu sprechen. In einer dreiteiligen Interviewsreihe behandeln wir den neuen Entwicklungsprozess innerhalb des OpenJFX-Projektes, die Pläne für JavaFX 12 und die Aussichten, JavaFX als UI-Alternative zu HTML zu etablieren.

JAXenter: Inwiefern unterscheidet sich JavaFX heute von seiner Zeit unter der Leitung von Oracle?

Im Interview:

Johan Vos (@johanvos), Java-Entwickler, Java Champion und Co-Founder von Gluon und LodgON.

Jonathan Giles (@JonathanGiles), Java Champion und JavaOne Rockstar.  Senior Developer Advocate bei Microsoft.

Dirk Lemmermann (@dlemmermann), unabhängiger Berater und Entwickler. Im letzten Jahr erhielt er den JavaOne Rockstar Award.

Donald Smith (@DonaldOJDK), Senior Director of Product Management bei Oracle.

Johan Vos: Oracle ist immer noch der Co-Leader für OpenJFX und stellt weiterhin viele Engineering-Ressourcen zur Verfügung. Die Ausrichtung des Projekts hat sich daher nicht geändert. Das Ziel ist es nach wie vor, ein qualitativ hochwertiges Framework bereitzustellen und zu pflegen, das von Java-Entwicklern zum Erstellen zeitgemäßer Client-Anwendungen verwendet werden kann.

Durch das Erstellen eines GitHub Mirrors ist es uns jedoch gelungen, mehr Interesse in der Community zu wecken. Eine Reihe von Entwicklern haben ihren ersten Commit überhaupt in ein OpenJDK-Projekt eingebracht. Diese Entwickler fanden auch den Weg zur Kernprojektinfrastruktur, und wir sehen einen starken Anstieg des Verkehrs auf der OpenJFX-Entwickler-Mailingliste.

Da OpenJFX nun offener ist, erhält das Projekt viel mehr Erweiterungen, die von der Community beigetragen werden.

Jonathan Giles: Ich würde sagen, dass JavaFX immer noch unter der Verwaltung von Oracle steht – jetzt ist die Community allerdings stärker als zuvor mit eingebunden. Unternehmen wie Gluon sind nun aktiv an der Wartung von Aspekten des OpenJFX-Projekts beteiligt (mit Johan Vos, einem nicht-Oracle Co-Leader von OpenJFX, zusammen mit Kevin Rushforth von Oracle). Gluon entwickelt Releases, treibt Community-Projekte wie die JavaFX-11-Projektseite voran und stellt langfristige Support-Optionen bereit. Die Community schreibt zudem Bibliotheken, bietet Beratungsdienstleistungen an und noch vieles weiteres.

Da OpenJFX nun offener ist und es den GitHub Mirror gibt, erhält  das Projekt auch viel mehr Erweiterungen, die von der Community beigetragen werden. Das ist super spannend!

Donald Smith: Oracle hat seit den Ankündigungen Anfang dieses Jahres enorme Fortschritte gemacht, um der Java-Community die Arbeit mit OpenJFX zu erleichtern. Wir haben hart daran gearbeitet, sicherzustellen, dass JavaFX unabhängig von einem JDK gebaut werden kann. Das ist unserer Meinung nach ein entscheidender Schritt, um sicherzustellen, dass die Community eine Führungsrolle übernehmen kann.

Johan Vos von Gluon hat seine Anstrengungen verstärkt und ist Co-Leader des OpenJFX-Projekt in OpenJDK geworden, was hervorragende Ergebnisse geliefert hat, wie z.B. die Verfügbarkeit von OpenJFX 11. Wir betrachten unsere Rolle und Beiträge nach wie vor als signifikant für OpenJFX und haben auch nicht vor, uns in absehbarer Zeit zurückzuziehen.

JAXenter: Was muss sich an JavaFX ändern, jetzt, da es unter der Verantwortung der Community steht?

Johan Vos: In der Vergangenheit haben Unternehmen und Einzelpersonen hauptsächlich Oracle verantwortlich gemacht, wenn es um die Definition und Umsetzung der Roadmap ging. Mit dem Öffnen des Projekts wird es deutlich, dass OpenJFX viel größer ist als das, was ein einzelnes Unternehmen leisten kann.

Wir sehen es nun immer häufiger, dass andere Unternehmen und Einzelpersonen Ideen entwickeln und diese auf der Mailingliste diskutieren und mit Vorschlägen zu deren Umsetzung kommen. Dieser Prozess muss fortgesetzt werden. Wir brauchen Unternehmen, die Input geben und die Arbeit an der Umsetzung intensivieren.

Oracle ist immer noch eine Größe in der JavaFX-Welt, doch jetzt haben auch andere Unternehmen die Chance, die Java-Client-Landschaft mitzugestalten.

Oracle ist immer noch eine Größe in der JavaFX-Welt, doch jetzt haben auch andere Unternehmen die Chance, die Java-Client-Landschaft mitzugestalten.

Jonathan Giles: Ich glaube nicht, dass sich etwas drastisch ändern muss. Ich denke, dass jetzt daran gearbeitet werden muss, die Lücken in JavaFX zu identifizieren, die von der Community bearbeitet werden können (in Form von Fehlersuche, Entwicklung neuer Funktionen, Schreiben von Dokumentationen, usw.).

Dirk Lemmermann: Ich denke, dass JavaFX ein echtes Open-Source-Projekt werden muss, in dem die Beiträge der Community wirkliche Wertschätzung erfahren. Und das Tempo muss erhöht werden, damit Bugfixes und neue Features auch eine Chance haben, es mit in das nächste Release zu schaffen.

Donald Smith: JavaFX wird weiterhin über das OpenJFX-Projekt auf OpenJDK entwickelt. Es ist seit langem ein Open-Source-Projekt, genau wie das JDK. Die wichtigsten Änderungen betrafen die Erleichterung für Entwickler, Korrekturen und Verbesserungen beizutragen und es vom JDK selbst zu entkoppeln. Andere Änderungen werden weiterhin über die normalen OpenJDK-Prozesse abgewickelt – wie bisher -, aber von der Community und nicht nur von Oracle gesteuert.

JAXenter: Was ist passiert, seit angekündigt wurde, dass JavaFX vom JDK entkoppelt wird? Ist der Prozess jetzt einfacher?

Johan Vos:  Hauptsächlich verfolgen wir immer noch die gleichen Verfahren wie in OpenJDK, um die Qualität, Stabilität und Ausgereiftheit von JavaFX zu garantieren. Darüber hinaus hat die Community, seit wir einen GitHub Mirror erstellt haben, automatische Tests mit AppVeyor und Travis hinzugefügt. Das machte es für Entwickler viel einfacher, an Pull Requests zu arbeiten und ihren Code zu testen, bevor sie nach Reviews fragen.

Jonathan Giles: Der Prozess hat sich verändert, aber ich denke, dass er sich auf eine gute Weise verändert hat. Ich denke, dass es zunächst ein paar Hindernisse geben wird, wenn die Entwickler zum neuen Ansatz übergehen, bei dem JavaFX-Bibliotheken über Maven ausgeliefert werden. Aber auf lange Sicht denke ich, dass die Änderungen im Prozess einen schnelleren Entwicklungszyklus ermöglichen und die Abhängigkeit beseitigen, eine bestimmte Java-Version auf seiner Maschine installieren zu müssen.

Auf lange Sicht wird die Änderung im Prozess einen schnelleren Entwicklungszyklus ermöglichen und eine Abhängigkeit davon beseitigt, dass der Benutzer eine bestimmte Java-Version auf seiner Maschine installiert hat.

Dirk Lemmermann: Auf jeden Fall! Jetzt gibt es einen einzigen Ort, an dem man an JavaFX arbeiten kann, und zwar das OpenJFX Repository auf GitHub. Jeder kann das Repository klonen und forken und JavaFX auf seinem eigenen Rechner weiterentwickeln. Einen Fehler zu beheben und einen Pull Request zu erstellen ist jetzt so einfach wie bei jedem anderen Open-Source-Projekt.

Donald Smith: Der Prozess für das Beitragen von Korrekturen wurde optimiert, um es Entwicklern zu erleichtern, Patches und neue Features zu testen und dann die Änderungen zur Überprüfung vorzuschlagen, die in JavaFX aufgenommen werden sollen. Wir suchen weiterhin nach Möglichkeiten, dies zu vereinfachen und gleichzeitig die hohe Qualität zu erhalten, die JavaFX-Anwender erwarten.

Vor den letzten Änderungen war JavaFX beispielsweise eng mit dem JDK integriert. Obwohl das vielleicht nach einer guten Sache klingt, bestand das Ergebnis darin, dass man keine eigenständige Version von JavaFX erstellen konnte, die von verschiedenen Java-SE-Implementierungen wie OpenJDK und Oracle JDK verwendet werden konnte. Wer JavaFX wollte, musste das komplette JDK nutzen. Jetzt, nach der Entkopplung, ist es möglich, an JavaFX unabhängig vom „Rest“ des JDK zu arbeiten.

JAXenter: Was ist dein erster Eindruck von JavaFX 11?

Johan Vos: Was für mich das große Ganze in JavaFX 11 ausmacht, ist die Tatsache, dass Entwickler nun auf die gleiche Weise JavaFX-Artefakte verwenden können wie bei anderen Softwarebibliotheken, da die Artefakte jetzt auf Maven Central deployt werden. Für Entwickler, die ein SDK bevorzugen, gibt es natürlich immer noch diese Option. Abgesehen davon hat JavaFX 11 neun Verbesserungen und 90 Bugfixes, verglichen mit JavaFX 10.

Im JavaFX 11 Release dreht sich alles um die Entkopplung vom JDK.

Dirk Lemmermann: Im JavaFX 11 Release dreht sich alles um die Entkopplung vom JDK. Es geht nicht um neue Features. Die Release Notes enthalten eine stattliche Liste von Bugfixes, eine kurze Liste von Verbesserungen und nur ein einziges wirklich neues Feature, nämlich das Robot API.

Donald Smith: Wir hoffen, dass sich JavaFX weiterentwickelt, um den sich ständig ändernden Bedürfnissen seiner Benutzer gerecht zu werden. Eines der Features, das wir uns in Zukunft erhoffen, ist die einfachere Integration von UI-Steuerelementen von Drittanbietern in JavaFX.

Im nächsten Teil der Interviewreihe werden wir uns auf die Weiterentwicklung von JavaFX, das nächste Release JavaFX 12 und mehr konzentrieren. Bleiben Sie dran!

Wer sich intensiver mit der Entwicklung von und mit JavaFX beschäftigen möchte, findet auf den JavaFX-Days-Zürich ein umfangreiches Programm an Workshops und Sessions. Weitere Infos gibt es unter www. javafx-days.com.

Verwandte Themen:

Geschrieben von
Gabriela Motroc
Gabriela Motroc
Gabriela Motroc ist Online-Redakteurin für JAXenter.com. Vor S&S Media studierte Sie International Communication Management an der The Hague University of Applied Sciences.
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "JavaFX-Standortbestimmung: JavaFX 11, ein Rückblick und ein Sprung nach vorn"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Dennis
Gast

Ich arbeite seit fast vier Jahren jeden Tag mit JavaFX.
Derzeit ist unsere Firma dabei unsere alte main Swing Oberfläche durch FX zu ersetzen. Bisher haben wir neue Fenster in FX gemacht und diese in Swing integriert, was ganz gut funktioniert(FXPane). Jedoch Swing Fenster in JavaFX zu integrieren ist leider mit viel mehr Bugs verbunden(SwingNode). Ich freue mich über die mögliche Zukunft von FX