Figured out the problem. We were shipping 26+ea-3 in the last version
and then bumped it to 26+ea-19.
When distributing applications through an .msi, e.g. via jpackage, the
msi will by default only replace files if certain conditions are met
like the file version being different.
(https://learn.microsoft.com/en-gb/windows/win32/msi/replacing-existing-files)
Since all JavaFX ea releases are marked as v26.0.0.0 when taking a look
at the properties of the shipped JavaFX .dlls, the msi installer does
not guarantee that it will upgrade the older JavaFX dlls as they both
have the same version. That way, some people might end up with the wrong
dlls after an update. I am still not sure why this only happens to some
users though.
I don't think this is a JavaFX issue really, more of an unfortunate
default behavior of msis.
On 30/12/2025 18:23, Michael Strauß wrote:
UnsatisfiedLinkError will never be thrown from native code.
In general, there's not much we can do about these kinds of
configuration errors.
Crashing is probably the best outcome here (a worse outcome would be
behavioral differences).
On Tue, Dec 30, 2025 at 5:59 PM Christopher Schnick <[email protected]> wrote:
Ah okay, I thought this could also be thrown from within the native
method GlassWindow::SetDarkFrame when it calls a dwmapi.dll function and
that dll is somehow broken or non-standard. If that is not possible,
then you can ignore this and I will file that as broken user system.
