Thanks Nir for referencing the PR.
There are more information and detailed numbers on the PR, but to add some context:
I did some tests by making the java.desktop requirement static.
That is, java.desktop is not automatically pulled into your application.
If you need it, it need to be put in your module.info, otherwise an exception is thrown as soon as a class from java.desktop is used.
When is java.desktop needed?
I did some tests by making the java.desktop requirement static.
That is, java.desktop is not automatically pulled into your application.
If you need it, it need to be put in your module.info, otherwise an exception is thrown as soon as a class from java.desktop is used.
When is java.desktop needed?
- javafx.base: When using any of the Bean Property classes from javafx.beans.property.adapter
- javafx.graphics: When using the printing classes, e.g. PrinterJob.createPrinterJob().showPrintDialog(..), or if you want to use ImageIO to load e.g. TIFF or SVG files
Benefit:
I created a modular Java runtime with JLink and measured the modules and disk size. Without java.desktop, the runtime got 13 MB smaller!
That is a nice decrease, especially if nothing what I mentioned above is needed. Creating a native installer like a .MSI will decrease the size further.
That is a nice decrease, especially if nothing what I mentioned above is needed. Creating a native installer like a .MSI will decrease the size further.
In my opinion, this is a great benefit. Unfortunately, as Kevin mentioned this is a somewhat incompatible change. So I'm interested in your opinion.
From my perspective, this is nice and if we don't want to go this route, I'm thinking for the first time ever about having a custom fork with this changes, which I would use for JLink (or can I easily patch those out when JLinking?).
I really don't like that, since now every other developer in the Team needs to build JFX, or take my custom JFX build.
But shipping a at least 13MB smaller .exe / even smaller .msi to the customer is very neat, also 'GreenIT' wise.
From my perspective, this is nice and if we don't want to go this route, I'm thinking for the first time ever about having a custom fork with this changes, which I would use for JLink (or can I easily patch those out when JLinking?).
I really don't like that, since now every other developer in the Team needs to build JFX, or take my custom JFX build.
But shipping a at least 13MB smaller .exe / even smaller .msi to the customer is very neat, also 'GreenIT' wise.
-- Marius
Gesendet: Mittwoch, 5. November 2025 um 10:56
Von: "Nir Lisker" <[email protected]>
An: "Kevin Rushforth" <[email protected]>
Betreff: Re: javafx.base and java.desktop
This is being implemented in https://github.com/openjdk/jfx/pull/1958.
On Sun, Nov 19, 2023 at 4:42 AM Nir Lisker <[email protected]> wrote:
Perhaps this is the right time to move this forward?I don't see why not. Except for changing the `requires` declaration in the module-info and mentioning it in the docs, is there anything else that needs to be changed?
On Sat, Nov 18, 2023 at 7:48 PM Kevin Rushforth <[email protected]> wrote:We would need to validate the assertion that an app can't doing anything useful without the app itself importing and using java.beans from the java.desktop module.
At a minimum this would need a CSR specifying this additional requirement that the app must depend on java.desktop in order to use the JavaFX beans property adapter classes.
If others think this is useful, we could consider this for JavaFX 23.
-- Kevin
On 11/18/2023 6:16 AM, Kevin Rushforth wrote:Perhaps the module can be declared 'requires static'.
That was my thinking as well, which is captured in https://bugs.openjdk.org/browse/JDK-8240844
Perhaps this is the right time to move this forward?
-- Kevin
On 11/17/2023 4:06 PM, Nir Lisker wrote:Hi,A previous discussion mentioned the removal of AWT dependencies. One of the points that Kevin brought up wasRefactor Java Beans implementation in javafx.base such that java.desktop is optionalJohn and I looked at this some time ago when we discussed the usage of the javafx base module outside of JavaFX, as its observables/binding capabilities are suitable for non-GUI applications, which currently have to pull in GUI modules as dependencies.The dependency is used in the property.adapter packages that bridge javafx.base properties with Java Beans. I think that these classes are seldom used.What could be a way to deal with that dependency? Perhaps the module can be declared 'requires static'. Or extract the adapter packages into a different "interop" module (javafx.javabeans) like javafx.swing?- Nir
