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
