JavaFX Integration

Wed Nov 5 10:40:07 UTC 2025

Hi Bruce,

I hear you. While there are non-technical issues involved as well, I
started looking for a technical approach where we can build OpenJFX using
the OpenJDK build system. While this does not imply that the JavaFX modules
are bundled with a JDK distribution, it is a major improvement and
simplification for those who want to. There is a discussion about this on
the openjfx-dev mailing list [1] and I have a github repository that
explains it [2]

Apart from the technical issue (which I believe is not that hard to
address, given my recent experimental work), I fully agree with the major
issue you mention: it is currently way too hard to have students quickly
opening an IDE with the latest JDK and run a quick Java application that
does some basic JavaFX rendering. We have docs for this at [3], but the
fact itself that these docs need to exist, plus the number of options you
see in the left menu (differences if you run standalone, using maven, using
gradle, using IntelliJ, NetBeans, Eclipe, VS Code) are an indication that
the operational effort is way too high.

With the current strong focus on AI, I am a bit surprised that there is no
more discussion about this. If you want to show to students that Java is
great for AI, I believe it is helpful to be able to create a simple
application using the most recent additions to the JDK, and then do some
basic visualization  of an

- Johan

[1]
https://mail.openjdk.org/pipermail/openjfx-dev/2025-September/056477.html
[2] https://github.com/openjdk-mobile/openjfx-build
[3] https://openjfx.io/openjfx-docs/

- Johan

Op wo 29 okt 2025 om 22:38 schreef Bruce K Haddon <haddon.brucek at gmail.com>:

> Java Friends,
>
>
>
> Once upon a time, JavaFX was included in the JDK, from Java 8 up to Java
> 10. JavaFX
>
> (in Java 11) then became a separate library, download, and install. As I
> understood it
>
> at the time, there were three basic reasons for this:
>
>
>
> 1.                  JavaFX contributed greatly to bloat in the size of
> the JDK
>
> 2.                  The separation allowed the JDK and the JavaFX SDK to
> evolve separately
>
> and at different paces and was to encourage more community involvement
>
> in the development of both the JDK and JavaFX.
>
> 3.                  The development and maintenance moved from Oracle to
> Gluon, in 2018,
>
> relieving Oracle of responsibility for JavaFX (The original JavaFX Script
> (F3
>
> started in 2005) language was revealed at the 2007 JavaOne convention,
>
> supported by Sun Microsystems at that time).
>
>
>
> Has not the time come to re-integrate JavaFX with the JDK? The above
> considerations
>
> are very much less applicable now:
>
>
>
> 1.                  The “bloat” question has been long addressed by the
> modularization of the
>
> JDK. It is no longer necessary to ship the entire JDK with an application,
> just
>
> the relevant modules. If JavaFX is not a requirement, then for distributed
>
> applications, the JavaFX modules (JavaFX is similarly modularized as the
>
> JDK) need not be included (as well as many other modules of the JDK for
>
> the average application).
>
> 2.                  The JDK and the JavaFX releases have kept in lockstep
> for some time
>
> now. The numbering is the same, the release dates are mostly with days
>
> if not hours the same. In particular, the releases of even security
>
> updates (third-digit of the release numbering) are coordinated.
>
> 3.                  Both JavaSE and JavaFX developments are available in
> open source
>
> (OpenJDK and  OpenJFX), although both Oracle and Gluon offer
>
> supported versions, with additional tools,  that are subject to
> licensing.
>
> Integrating the releases still permits community involvement and
>
> innovation is either case.
>
>
>
> It appears that there is close co-operation between the open development
> of the JDK
>
> and of the JavaFX SDK, and the releases of both libraries could quite
> usefully be
>
> under one administration.
>
>
>
> Further, it would be of great convenience to developers not to have to
> make two
>
> installations and then configure their IDEs to access both libraries (not
> really easy in
>
> almost all IDEs, requiring understanding of many otherwise ignorable
> options of each
>
> IDE). In particular (my prime interest) is that it would simplify life for
> early students of
>
> Java and also provide the realization that the JDK and the JavaFX features
> are on an
>
> equal footing in terms of use, access, and support, rather than JavaFX
> being an
>
> optional and difficult added learning issue.
>
>
>
> The relationship between OpenJDK and Oracle shows that commercial interest
> and
>
> open-source interest can co-exist, as does the relationship between Gluon
> and
>
> OpenJFX. There appears to be no reason that if the JavaFX modules were
> included
>
> in the one (modularized) download with the JDK modules that that either
> Oracle’s or
>
> Gluon’s commercial interests would be affected.
>
>
>
> It is both my belief and my recommendation that the time has come for the
> re-
>
> integration of JavaFX (as the preferred GUI feature) with the rest of the
> JDK.
>
>
>
> With the hope that your development proceeds smoothly,
>
>
>
> Bruce K. Haddon
>
>
> ------------------------------
>
> Dr. Bruce K. Haddon
>
> 1506 Chambers Drive
>
> +1 303/499 6240
>
> Boulder, CO 80305-7002
>
> Haddon,BruceK at gmail.com <Bruce.Haddon at colorado.edu>
>
>
> "Science is facts; just as houses are made of stones, so is science made
> of facts; but a pile of stones is not a house and a collection of facts is
> not necessarily science."—Henri Poincare
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/discuss/attachments/20251105/0884fe86/attachment.htm>