JavaFX Integration

Wed Oct 29 22:40:51 UTC 2025

> 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.

I will say that there are JDK vendors - Zulu comes to mind - which do
include the JavaFX modules in their JDK downloads. Any institution that
could afford a JCK or individuals in a context where they don't need it to
be "Java (tm) (c) (r)" could also play in that game. This doesn't justify
the current situation where JavaFX is one of the most annoying libraries to
procure, but it is an option for the students you interact with.

What isn't clear from what you described is why *now* is the time for a
broad spectrum of vendors to reintegrate JavaFX. JavaFX was separated in
11, after the module system was introduced. The story would be different if
it was, say, not included in distributions from 7 onwards. Nothing has
changed since its removal. Presumably the political factors in play have
not changed - if Oracle starts including JavaFX binaries in their JDKs they
provide paid support for, they need to start providing paid support for
JavaFX. That would entail un-offloading or a contract with Gluon or...god
who knows man.

JavaFX is not the only thing which was removed from downloads of JDKs and
is now a PITA to procure. JAXB used to come with Java 1.6 and now you have
to get a zip download in order to get the cli tools like xjc. In both cases
there is an aspect of the thing excised from the JDK (wanting to be on the
module path, coming with CLI tooling) which grates against what is easy and
what is difficult to do in the Java ecosystem. My personal take remains
that tackling the dependency procurement issue is probably more worth the
time and, if tackled properly, can sidestep these issues.

I think it is enlightening to flip the situation. You can use many of the
same bloat justifications to remove the whole java.desktop (swing/awt/etc.)
module from a JDK. What problems would you face in doing so?

* Dependencies as they exist in the wild do not specify if they depend on
java.desktop unless they themselves have module infos. Even then that
information is not reflected in their dependency manifests since those are
specified as pom.xml files
* java.desktop comes with native code that would eventually have to be
allowlisted by --enable-native-access. This is expected for libraries, but
since the JDK vendor is co-developing this module it gets to be trusted
* java.desktop currently can be assumed to always be on the module path. If
you distribute it as a jar - which is the only thing dependency procurement
tech currently understands - people could put it on the --class-path or
shove it into uberjars and get at unexported packages. This would create
new maintenance burdens for the folks developing Java (that they just got
through). The same maintenance burdens that were created for JavaFX.
* java.desktop currently not only makes use of qualified exports (only
jdk.accessibility and jdk.unsupported.desktop can use the sun.awt package)
it uses module hashes, like the rest of the jdk, to ensure that those
qualified exports only happen for exactly the same version of those modules
it was built against. That also goes out the window in any way we have to
distribute libraries to the masses right now.
* java.desktop is developed as part of openjdk but is ultimately
distributed by any number of vendors. If you shoved java.desktop onto a
maven repository (as has been done with JavaFX) you'd end up with
adoptium/java.desktop, oracle/java.desktop, etc. All of those would be
treated as distinct dependencies.
* java.desktop has a mountain of native code and if you move off of JMODs
you need to do the jank extract-at-runtime-from-jar strategy that all
ecosystem libraries do when they want to use native code and that needs to
be retrofitted in.
* There is a whole slew of info in the legal/ section of a java.desktop JMOD
that really doesn't fit into how maven dependencies represent that info.
You'd be jamming even more into jars.

And so on.

I think you are right to be frustrated. But I think that investing in
making a world where JavaFX (or any module) coming separately isn't a
horror show is probably more practical than winning corporate resource
allocation battles from the outside in.

On Wed, Oct 29, 2025 at 5:40 PM Bruce K Haddon <haddon.brucek at gmail.com>
wrote:

> 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/20251029/43bb16aa/attachment-0001.htm>