From iostream64 at gmail.com Tue Oct 28 12:15:44 2025 From: iostream64 at gmail.com (Igor) Date: Tue, 28 Oct 2025 14:15:44 +0200 Subject: Hello from a new member Message-ID: Hi everyone, I?m writing to introduce myself, as Mr. Dalibor Topic encouraged me to do. My name is Igor, and I?m excited to become part of this community. I have several years of professional experience in both C++ and Java, and I hope to contribute wherever I can. Some time ago, I started exploring the internals of the JDK while working on my pet project, a JVM implementation from scratch - this led me here. Since then, I?ve become familiar with parts of the OpenJDK codebase and now feel ready to start contributing. Regards, Igor Rudenko -------------- next part -------------- An HTML attachment was scrubbed... URL: From haddon.brucek at gmail.com Wed Oct 29 17:49:46 2025 From: haddon.brucek at gmail.com (Bruce K Haddon) Date: Wed, 29 Oct 2025 11:49:46 -0600 Subject: JavaFX Integration Message-ID: <008301dc48fc$6ab04e50$4010eaf0$@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 "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: From ethan at mccue.dev Wed Oct 29 22:40:51 2025 From: ethan at mccue.dev (Ethan McCue) Date: Wed, 29 Oct 2025 18:40:51 -0400 Subject: JavaFX Integration In-Reply-To: <008301dc48fc$6ab04e50$4010eaf0$@gmail.com> References: <008301dc48fc$6ab04e50$4010eaf0$@gmail.com> Message-ID: > 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 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 > > > "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: