<div dir="ltr">> 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.<br><br>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.<br><br>What isn't clear from what you described is why <i>now</i> 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.<br><br>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.<br><br>I think it is enlightening to flip the situation. You can use many of the same bloat justifications to remove the whole <font face="monospace">java.desktop</font> (swing/awt/etc.) module from a JDK. What problems would you face in doing so?<br><br>* Dependencies as they exist in the wild do not specify if they depend on <font face="monospace">java.desktop</font> 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<br>* <font face="monospace">java.desktop</font> 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<div>* <font face="monospace">java.desktop</font><font face="arial, sans-serif"> 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 </font><font face="monospace">--class-path</font><font face="arial, sans-serif"> 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.<br></font>* <font face="monospace">java.desktop</font><font face="arial, sans-serif"> currently not only makes use of qualified exports (only </font><font face="monospace">jdk.accessibility</font><font face="arial, sans-serif"> and </font><font face="monospace">jdk.unsupported.desktop</font><font face="arial, sans-serif"> can use the </font><font face="monospace">sun.awt</font><font face="arial, sans-serif"> 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.<br></font>* <font face="monospace">java.desktop</font><font face="arial, sans-serif"> is developed as part of openjdk but is ultimately distributed by any number of vendors. If you shoved </font><font face="monospace">java.desktop</font><font face="arial, sans-serif"> onto a maven repository (as has been done with JavaFX) you'd end up with </font><font face="monospace">adoptium/java.desktop</font><font face="arial, sans-serif">, </font><font face="monospace">oracle/java.desktop</font><font face="arial, sans-serif">, etc. All of those would be treated as distinct dependencies.<br></font>* <font face="monospace">java.desktop</font><font face="arial, sans-serif"> 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.<br></font>* There is a whole slew of info in the legal/ section of a <font face="monospace">java.desktop</font><font face="arial, sans-serif"> JMOD that really doesn't fit into how maven dependencies represent that info. You'd be jamming even more into jars.<br></font><br>And so on.<br><br>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.<br><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Oct 29, 2025 at 5:40 PM Bruce K Haddon <<a href="mailto:haddon.brucek@gmail.com">haddon.brucek@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-1745234007211344515"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="m_-1745234007211344515WordSection1"><p class="MsoNormal"><span style="font-size:11pt">Java Friends, <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">Once upon a time, JavaFX was included in the JDK, from Java 8 up to Java 10. JavaFX <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">(in Java 11) then became a separate library, download, and install. As I understood it <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">at the time, there were three basic reasons for this: <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p><p class="m_-1745234007211344515MsoListParagraph" style="margin-left:54pt"><u></u><span style="font-size:11pt"><span>1.<span style="font:7pt "Times New Roman"">                  </span></span></span><u></u><span style="font-size:11pt">JavaFX contributed greatly to bloat in the size of the JDK <u></u><u></u></span></p><p class="m_-1745234007211344515MsoListParagraph" style="margin-left:54pt"><u></u><span style="font-size:11pt"><span>2.<span style="font:7pt "Times New Roman"">                  </span></span></span><u></u><span style="font-size:11pt">The separation allowed the JDK and the JavaFX SDK to evolve separately <u></u><u></u></span></p><p class="m_-1745234007211344515MsoListParagraph" style="margin-left:54pt"><span style="font-size:11pt">and at different paces and was to encourage more community involvement <u></u><u></u></span></p><p class="m_-1745234007211344515MsoListParagraph" style="margin-left:54pt"><span style="font-size:11pt">in the development of both the JDK and JavaFX.<span>  </span><u></u><u></u></span></p><p class="m_-1745234007211344515MsoListParagraph" style="margin-left:54pt"><u></u><span style="font-size:11pt"><span>3.<span style="font:7pt "Times New Roman"">                  </span></span></span><u></u><span style="font-size:11pt">The development and maintenance moved from Oracle to Gluon, in 2018, <u></u><u></u></span></p><p class="MsoNormal" style="margin-left:18pt;text-indent:36pt"><span style="font-size:11pt">relieving Oracle of responsibility for JavaFX (The original JavaFX Script (F3 <u></u><u></u></span></p><p class="MsoNormal" style="margin-left:18pt;text-indent:36pt"><span style="font-size:11pt">started in 2005) language was revealed at the 2007 JavaOne convention, <u></u><u></u></span></p><p class="MsoNormal" style="margin-left:18pt;text-indent:36pt"><span style="font-size:11pt">supported by Sun Microsystems at that time).<u></u><u></u></span></p><p class="MsoNormal" style="text-indent:36pt"><span style="font-size:11pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">Has not the time come to re-integrate JavaFX with the JDK? The above considerations <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">are very much less applicable now: <u></u><u></u></span></p><p class="m_-1745234007211344515MsoListParagraph" style="margin-left:54pt"><span style="font-size:11pt"><u></u> <u></u></span></p><p class="m_-1745234007211344515MsoListParagraph" style="margin-left:54pt"><u></u><span style="font-size:11pt"><span>1.<span style="font:7pt "Times New Roman"">                  </span></span></span><u></u><span style="font-size:11pt">The “bloat” question has been long addressed by the modularization of the <span> </span><u></u><u></u></span></p><p class="m_-1745234007211344515MsoListParagraph" style="margin-left:54pt"><span style="font-size:11pt">JDK. It is no longer necessary to ship the entire JDK with an application, just<u></u><u></u></span></p><p class="m_-1745234007211344515MsoListParagraph" style="margin-left:54pt"><span style="font-size:11pt">the relevant modules. If JavaFX is not a requirement, then for distributed <u></u><u></u></span></p><p class="m_-1745234007211344515MsoListParagraph" style="margin-left:54pt"><span style="font-size:11pt">applications, the JavaFX modules (JavaFX is similarly modularized as the<u></u><u></u></span></p><p class="m_-1745234007211344515MsoListParagraph" style="margin-left:54pt"><span style="font-size:11pt">JDK) need not be included (as well as many other modules of the JDK for <u></u><u></u></span></p><p class="m_-1745234007211344515MsoListParagraph" style="margin-left:54pt"><span style="font-size:11pt">the average application). <u></u><u></u></span></p><p class="m_-1745234007211344515MsoListParagraph" style="margin-left:54pt"><u></u><span style="font-size:11pt"><span>2.<span style="font:7pt "Times New Roman"">                  </span></span></span><u></u><span style="font-size:11pt">The JDK and the JavaFX releases have kept in lockstep for some time <u></u><u></u></span></p><p class="m_-1745234007211344515MsoListParagraph" style="margin-left:54pt"><span style="font-size:11pt">now. The numbering is the same, the release dates are mostly with days <u></u><u></u></span></p><p class="m_-1745234007211344515MsoListParagraph" style="margin-left:54pt"><span style="font-size:11pt">if not hours the same. In particular, the releases of even security <u></u><u></u></span></p><p class="m_-1745234007211344515MsoListParagraph" style="margin-left:54pt"><span style="font-size:11pt">updates (third-digit of the release numbering) are coordinated. <u></u><u></u></span></p><p class="m_-1745234007211344515MsoListParagraph" style="margin-left:54pt"><u></u><span style="font-size:11pt"><span>3.<span style="font:7pt "Times New Roman"">                  </span></span></span><u></u><span style="font-size:11pt">Both JavaSE and JavaFX developments are available in open source <u></u><u></u></span></p><p class="m_-1745234007211344515MsoListParagraph" style="margin-left:54pt"><span style="font-size:11pt">(OpenJDK and <span> </span>OpenJFX), although both Oracle and Gluon offer <u></u><u></u></span></p><p class="m_-1745234007211344515MsoListParagraph" style="margin-left:54pt"><span style="font-size:11pt">supported versions, with additional tools, <span> </span>that are subject to licensing. <u></u><u></u></span></p><p class="m_-1745234007211344515MsoListParagraph" style="margin-left:54pt"><span style="font-size:11pt">Integrating the releases still permits community involvement and <span> </span><u></u><u></u></span></p><p class="m_-1745234007211344515MsoListParagraph" style="margin-left:54pt"><span style="font-size:11pt">innovation is either case. <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">It appears that there is close co-operation between the open development of the JDK <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">and of the JavaFX SDK, and the releases of both libraries could quite usefully be <span> </span><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">under one administration. <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">Further, it would be of great convenience to developers not to have to make two <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">installations and then configure their IDEs to access both libraries (not really easy in <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">almost all IDEs, requiring understanding of many otherwise ignorable options of each <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">IDE). In particular (my prime interest) is that it would simplify life for early students of <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">Java and also provide the realization that the JDK and the JavaFX features are on an<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"> equal footing in terms of use, access, and support, rather than JavaFX being an <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">optional and difficult added learning issue. <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">The relationship between OpenJDK and Oracle shows that commercial interest and <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">open-source interest can co-exist, as does the relationship between Gluon and <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">OpenJFX. There appears to be no reason that if the JavaFX modules were included <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">in the one (modularized) download with the JDK modules that that either Oracle’s or <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">Gluon’s commercial interests would be affected. <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">It is both my belief and my recommendation that the time has come for the re-<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">integration of JavaFX (as the preferred GUI feature) with the rest of the JDK. <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">With the hope that your development proceeds smoothly,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">Bruce K. Haddon <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p><table border="0" cellpadding="0" width="520" style="width:390pt"><tbody><tr><td colspan="2" style="padding:0cm"><div class="MsoNormal" align="center" style="text-align:center"><span><hr size="2" width="100%" align="center"></span></div><p class="MsoNormal"><span>Dr. Bruce K. Haddon<u></u><u></u></span></p></td></tr><tr><td style="padding:0cm"><p class="MsoNormal"><span>1506 Chambers Drive<u></u><u></u></span></p></td><td style="padding:0cm"><p class="MsoNormal" align="right" style="text-align:right"><span>+1 303/499 6240<u></u><u></u></span></p></td></tr><tr><td style="padding:0cm"><p class="MsoNormal"><span>Boulder, CO 80305-7002<u></u><u></u></span></p></td><td style="padding:0cm"><p class="MsoNormal" align="right" style="text-align:right"><span><a href="mailto:Bruce.Haddon@colorado.edu" target="_blank"><span style="color:rgb(5,99,193)">Haddon,BruceK@gmail.com</span></a><u></u><u></u></span></p></td></tr><tr><td colspan="2" style="padding:0cm"><p class="MsoNormal" align="right" style="text-align:right"><span><br>"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 <u></u><u></u></span></p></td></tr></tbody></table><p class="MsoNormal"><span style="font-family:Calibri,sans-serif"><u></u> <u></u></span></p><p class="MsoNormal"><u></u> <u></u></p></div></div></div></blockquote></div>