javafx.base and java.desktop

[Nir Lisker]

The removal from the base module is straightforward and should continue in
my opinion. The one from graphics is more troublesome because it will
remove functionality that might otherwise be assumed and requires planning.

I suggest using the current PR for decoupling the base module and if a
similar decoupling is done for the graphics module then it should be done
in a different PR.

On Wed, Nov 5, 2025 at 12:46 PM Marius Hanl <mariushanl at web.de> wrote:

> 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?
>
>    - 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.
>
> 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.
>
> -- Marius
>
> *Gesendet: *Mittwoch, 5. November 2025 um 10:56
> *Von: *"Nir Lisker" <nlisker at gmail.com>
> *An: *"Kevin Rushforth" <kevin.rushforth at oracle.com>
> *CC: *openjfx-dev at openjdk.org
> *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 <nlisker at gmail.com> 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 <
>> kevin.rushforth at oracle.com> 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 was
>>>
>>>
>>>>  Refactor Java Beans implementation in javafx.base such that
>>>> java.desktop is optional
>>>
>>>
>>> John 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
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251105/36aba083/attachment-0001.htm>