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 > > >
