Hey Nir,
that is why I asked this question about the DLLs in the first place.
I'm actually not sure at all, so I did a test run.
So far, nobody complained, so it seems that all DLLs required usually
exist. But note that I don't use javafx.web and all machines are on
Windows 11.
And the application is created with JLink + JPackage,
It would be interesting to know which DLLs are definitely present, but I
haven't looked into it any further. Or which DLLs already come from
java.base.
I'm just experimenting a little bit right now.
-- Marius
Am 12.04.2026 um 23:01 schrieb Nir Lisker:
Marius,
How would you know if the target machine has the required files? Are
you able to ask the clients?
On Sun, Apr 12, 2026, 23:30 Marius Hanl <[email protected]> wrote:
No problem! Thanks for the explaination and the issue links - helps a
lot to understand.
I also wondered whether some DLLs might not be included in every
Windows
distribution. But didn't know about the JDK <-> JavaFX mismatch.
Makes sense! I think a flag could be useful indeed.
I wonder how Johans openjfx-build project solves this - I would guess
that the same DLLs are used here as well. Which then solves this
problem
as well.
> It would be a (minor) breaking change to remove it and deliver it
> separately
I wonder if we could introduce a flag as well for it. My main
motivation
is that I don't want to ship code that is not needed.
The size improvement is nice, but more so that less code = less
(security) risks. Admittedly, I don't see a big risk in
javafx-swt.jar,
still something to consider.
-- Marius
Am 11.04.2026 um 17:33 schrieb Kevin Rushforth:
> Sorry for not replying earlier.
>
>> First:
>> This might be dumb question (maybe :P), but why do we copy the
>> Windows DLLs into the javafx.graphics module?
>> I just removed them to test what happens, and to my surprise, the
>> application still works and the NativeLibLoader will load those
from
>> Windows itself instead.
>> That also means that those DLLs don't need to be copied into
the TEMP
>> folder when working with e.g. Maven.
>> But more interesting to me, this will reduce the size of my
JPackaged
>> Application by ~3 MB. Which is not bad.
>> So I wonder, why this is needed, and if it makes sense to turn off
>> this behavior (optionally) with a Gradle flag.
>
> Not a dumb question at all. See JDK-8281089 [1] and a
somewhat-related
> JDK-8289952 [2] for why we need to do this. The basic problem is
that
> if there is a mismatch between the version of the Microsoft Visual
> Studio toolchain used by the JDK and by JavaFX, some of the DLLs or
> functions within those DLLs won't be available at runtime on a
system
> that doesn't otherwise have the latest version installed in the
> C:\Windows\System32 directory. This isn't just a theoretical
concern.
> We've seen actual failures (multiple times) as a result of not
doing
> this.
>
> Having a flag to turn off the copying the redistributable DLLs for
> developer builds might be useful.
>
>> Second:
>> Why does the javafx.graphics module contains a 'javafx-swt.jar'?
>> While it is not that big (0.32MB), it seems to be a bit weird.
>> Note: Those claims can be verified when opening the latest
>> javafx-graphics-27-ea+5-win.jar with 7z (for example).
>> Note2: I did not check the other platforms. I'm mostly
interested in
>> Windows, because that is what most of the companies use in the
industy.
>
> It is admittedly an odd place for it. Because javafx-swt.jar is
> (necessarily) an automatic module, there isn't a good way to
provide
> it on its own -- at least not one we could think of. We could have
> created a dummy "javafx.swt.provider" (or similar) module that
would
> depend on javafx.graphics, export no APIs, and include the
> javafx-swt.jar automatic module. In hindsight, that would have
been a
> better choice than including it with javafx.graphics, which we did
> just because it seemed like a somewhat convenient way to distribute
> it. It would be a (minor) breaking change to remove it and
deliver it
> separately, but something we could consider if there was a good
> reason. Not sure it's worth it.
>
> -- Kevin
>
> [1] https://bugs.openjdk.org/browse/JDK-8281089
> [2] https://bugs.openjdk.org/browse/JDK-8289952
>
>
> On 4/11/2026 3:12 AM, Marius Hanl wrote:
>> Bump, anyone has an idea? I'm still very much interested why
this is
>> the case.
>> Especially as this saves quite a bit of the final binary size.
>>
>> -- Marius
>>
>> Am 25.02.2026 um 20:37 schrieb Marius Hanl:
>>> Hey all, when checking how the size of JavaFX applications can be
>>> reduced further (beside removing the hard dependency on
>>> java. desktop), I found two interesting things I was wondering
>>> about. First: This might be dumb question (maybe :P), but
>>> Hey all,
>>> when checking how the size of JavaFX applications can be reduced
>>> further (beside removing the hard dependency on java.desktop), I
>>> found two interesting things I was wondering about.
>>> First:
>>> This might be dumb question (maybe :P), but why do we copy the
>>> Windows DLLs into the javafx.graphics module?
>>> I just removed them to test what happens, and to my surprise, the
>>> application still works and the NativeLibLoader will load
those from
>>> Windows itself instead.
>>> That also means that those DLLs don't need to be copied into the
>>> TEMP folder when working with e.g. Maven.
>>> But more interesting to me, this will reduce the size of my
>>> JPackaged Application by ~3 MB. Which is not bad.
>>> So I wonder, why this is needed, and if it makes sense to turn
off
>>> this behavior (optionally) with a Gradle flag.
>>> Second:
>>> Why does the javafx.graphics module contains a 'javafx-swt.jar'?
>>> While it is not that big (0.32MB), it seems to be a bit weird.
>>> Note: Those claims can be verified when opening the latest
>>> javafx-graphics-27-ea+5-win.jar with 7z (for example).
>>> Note2: I did not check the other platforms. I'm mostly
interested in
>>> Windows, because that is what most of the companies use in the
industy.
>>> For more Context: At this point in time, I only ever had to
create
>>> Windows binary files (.exe or .msi) for those projects (Wished by
>>> the customer).
>>> Even more Context: With removing the hard dependency to
>>> java.desktop, not shipping the DLLs and the SWT jar, my
applications
>>> usually went from ~70 MB to ~57MB. Using JMods.
>>> This is a pretty good result, especially when we compare against
>>> other ways to build and package an Application like Electron,
where
>>> applications are usually around ~100 MB, that sometimes can be
>>> optimized to around ~70 MB.
>>> -- Marius
>
