OpenJFX von JDK 11 entkoppelt? Nicht verwunderlich!

JavaFX als eigenständiges Modul: Warum das schon lange überfällig war

Johan Vos

© Shutterstock.com / Africa Studio

JavaFX wurde 2007 auf der JavaOne angekündigt und war seitdem Teil des JDKs. Nun soll es aus diesem herausgelöst als eigenständiges Modul zur Verfügung gestellt werden. Java Champion Johan Vos erklärt in diesem Artikel wie sich JavaFX über die Jahre entwickelt hat und welche Gründe es für die Entkopplung gibt. Er legt zudem dar, warum es absolut Sinn macht, die Weiterentwicklung von JavaFX in ein offenes System zu überführen.

Als 2007 JavaFX angekündigt wurde, war es Suns erster, ernsthafter Versuch, die alternde AWT/Swing-Technologie durch eine modernere Client-Plattform zu ersetzen. Die neue Plattform sollte unter anderem dazu fähig sein, Benutzeroberflächen (UI) zu rendern.

Eins der Markenzeichen von JavaFX ist die Trennung zwischen den APIs, die Entwickler zum Erstellen von Benutzeroberflächen verwenden, und den Rendering-Engines, die sicherstellen, dass die Benutzeroberfläche auf dem Gerät gerendert wird. Für Windows Plattformen benutzt die JavaFX-Rendering-Pipeline Direct3D, während für andere Plattformen die Rendering-Pipelines auf OpenGL basieren. Die Trennung hat den Vorteil, dass die JavaFX APIs nicht verändert werden müssen, sobald neue Hardware-Rendering-Techniken zur Verfügung stehen. JavaFX erlaubt es, ganz im Geiste von Java, plattformübergreifende Anwendungen zu erstellen, die selbst dann noch laufen, wenn die unterliegenden Implementierungen verändert werden.

JavaFX wurde anfänglich als vor allem interessant für Spiele und ähnliches angesehen. Auch wenn das immer noch der Fall sein mag, so gibt es in der Zwischenzeit eine große Zahl von JavaFX-Entwicklern, die in den unterschiedlichsten Branchen arbeiten, in denen es einen Bedarf an hochperformanten, grafischen Operationen in Bezug auf sensible Daten gibt. Es ist diese Kombination aus JavaFX-Rendering-APIs, der Sicherheitsfunktionalität des (Kern-)JDKs sowie den Bibliotheken von Drittanbietern, die es möglich machen ausgereifte, zukunftssichere und optisch ansprechende Desktop-, Mobil- oder Embedded-Anwendungen zu erstellen. Doch da sehr viele dieser Anwendungen hinter verschlossenen Türen entwickelt und genutzt werden, ist es bisweilen schwer, die tatsächliche Popularität von JavaFX einzuschätzen. Doch gerade innerhalb der Wissenschaftsgemeinde wird JavaFX immer häufiger eingesetzt, zum Beispiel beim Deep Space Trajectory Explorer.

Lesen Sie auch: JavaFX fliegt aus dem JDK: Oracle liefert Java 11 ohne JavaFX aus

Mit der wachsenden Popularität von KI und Deep Learning werden JavaFX und Client Java im Allgemeinen auch immer interessanter für Entwickler, die die Java-Plattform und die UI APIs von JavaFX nutzen wollen, während sie gleichzeitig Funktionalitäten bereitstellen, die Deep-Learning-Algorithmen beinhalten. Im Vergleich zu Swing/AWT sind die APIs von JavaFX stärker auf heutige Konzepte der UI-Entwicklung ausgelegt, während die zugrundeliegenden Rendering-Engines die Hardware-Beschleunigung nutzen. In dieser Kombination stellt JavaFX eine moderne UI-Plattform dar, die auf das gesammelte Wissen aus 25 Jahren Java zurückgreift.

JavaFX ist mehr als nur das Rendern von Benutzeroberflächen. Die Plattform enthält eine solide Basis für die Client-Entwicklung im Allgemeinen (unter Berücksichtigung von Threading, Parallelität, Beobachtbarkeit usw.). In Folge dessen existieren jede Menge Dinge, die ein Entwickler lernen kann oder können sollte. Zudem gibt es eine große Auswahl an Ressourcen, die von Büchern über Kürse bis hin zu Tutorials reichen. Bemerkenswert ist unter anderem, dass Tutorials für Scene Builder – das UI-Tool, mit dem eine JavaFX-Benutzeroberfläche durch Dragging und Konfigurieren von Komponenten erstellt werden kann, anstatt sie zu programmieren – auf YouTube sehr beliebt sind.

Java 11 bringt JavaFX als separates, vom JDK entkoppeltes Modul

Erst kürzlich kündigte Oracle an, dass die JavaFX-Module von der der JDK-Kerndistribution entkoppelt werden sollen. Und wenn man sich die Ziele der Modularität vor Augen hält, so ist dieser Schritt durchaus sinnvoll. Einer der Hauptgründe, weshalb die Java-Plattform ein modulares System benötigte, ist, dass sie seit ihrer Veröffentlichung sehr stark gewachsen ist. Die Java-Kerndistributationen von Java (Oracle JDK) wurden um eine Vielzahl von Funktionen erweitert. Trotzdem nutzen nahezu alle Java-Projekte in der Produktion die Bibliotheken von Drittanbietern. Entwickler verlassen sich auf Tools wie Ant, Maven oder Gradle, um abhängige Bibliotheken von z.B. Maven Central oder jcenter herunterzuladen und diese Abhängigkeiten zu verwalten. Der Vorteil dieses Verteilungsmechanismus besteht darin, dass eine feingranulierte Steuerung möglich ist und man Nutzern nicht sagen muss, dass sie die exakten Versionen der richtigen Komponenten, auf die man sich verlässt, herunterladen müssen.

Unterschiedliche Komponenten entwickeln sich in unterschiedlichen Geschwindigkeiten. Während Abwärtskompatibilität eines der Hauptmerkmale von Java ist, verlassen sich Entwickler in vielen Fällen auf eine bestimmte Version einer Bibliothek, die in ihrer Anwendung verwendet wird. Wenn diese Bibliothek fest JDK ins implementiert wäre, hätte das schwerwiegende Folgen, denn das JDK ist immer noch eine monolithische Software, die manuell heruntergeladen und auf dem jeweiligen System installiert wird.

Der Kern des JDK ist ein wunderbares Kunstwerk, das von sehr talentierten Engineers gepflegt wird. Um die Qualität dieses Kerns insbesondere bei schnellen Release-Zyklen zu gewährleisten, sollten alle Komponenten, die außerhalb des Kerns gewartet werden können, separat gewartet und veröffentlicht werden. Daher ist es nicht verwunderlich, dass die OpenJFX-Module vom Kern entkoppelt werden – es ist eher überraschend, dass es noch so viele andere Module im Kern gibt.

Lesen Sie auch: FX-Test: JUnit-Tests für JavaFX- und OSGi-Anwendungen

Es steht in der Tradition von JavaFX, ein sehr starkes und weitreichendes, stimmliches Ökosystem zu haben. Es gibt viele Bibliotheken, die auf JavaFX basieren und von Drittanbietern erstellt wurden. JavaFX wurde zudem auf verschiedene Plattformen portiert, einschließlich Embedded- und Mobile-Plattformen (Android/iOS) außerhalb von Oracle. Daher ist es sinnvoll, die Entwicklung von JavaFX in ein offenes System zu verlagern. Das GitHub Repository ist ein Spiegelbild dieser Idee. Die heutige Entwicklung findet immer häufiger auf GitHub statt, und durch die Einladung an externe Entwickler über GitHub zur JavaFX-Plattform beizutragen, entwickelt sich JavaFX mehr und mehr zu einer offenen, entwicklerfreundlichen Plattform.

Die zunehmende Einbindung der Java-Entwicklergemeinde in die Java-Kernentwicklung ist nicht neu. Das AdoptOpenJDK-Projekt ist eine von der Gemeinschaft organisierte Initiative, die seit einigen Jahren daran arbeitet, Distributionen auf Basis des OpenJDK-Quellcodes zu erstellen. In Zukunft können die JavaFX-Module unter Nutzung der AdoptOpenJDK-Infrastruktur erstellt und die daraus resultierenden Artefakte auf Plattformen wie Maven Central und jcenter hochgeladen werden. Die Diskussionen über dieses Thema zwischen Oracle und der größeren JavaFX-Community sind im Gange.

Geschrieben von
Johan Vos
Johan Vos
Johan Vos started working with Java in 1995, as part of his PhD research. He joined the Blackdown team and ported Java 1.2 to Linux/SPARC. Johan has been a Java consultant ever since, and worked for a number of companies (e.g. The Reference, Acunia). He co-founded LodgON, where the main focus is on social networking software and recently became a Java Champion. He was part of the Core Platform Expert Group of OSGi that created the OSGi platform specifications. His main technology interests are currently GlassFish and JavaFX. He holds an Msc in civil engineering (mining) and a PhD in Applied Physics.
Kommentare
  1. Peter2018-03-17 20:33:16

    Meiner Meinung hat JavaFX 4 Jahre verschenkt mit dem unsäglichen JavaFX Script aus Version 1. Das dann 2011 in die Tonne kam und nicht gerade für Vertrauen gesorgt hat. Das jetzt modularisiert wird, ist ja wohl mit Java9 klar. Das es nicht mehr in die SE kommt, verstehe ich jetzt nicht. Dann müsste AWT/Swing ja auch rausfliegen. Nun gut, mit Oracles Cloud-Strategie passt es dann wieder; wer braucht GUI code in der Cloud ?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.