Oh, thanks, didn't knew that. I tried the JMOD files provided by Gloun
company with a local build. Works!
But how can this be integrated into an automatic/CI build? Using a more
or less arbitrary url pointing to a third-party website downloading a
zip file of unknown structure would result in a "ducktape build" and is
not very resilient against any changes. Furthermore, some build systems
(i.e., ubuntu-ppa) do not allow external downloads.
Does automatic build examples exist which are jlinking JFX to a custom JRE?
Best wishes,
Armin
Am 16/11/2022 um 15:39 schrieb Kevin Rushforth:
Leaving aside the question of signed libraries, if you are using
jpackage / jlink to create a custom Java runtime with the JavaFX
modules, then you should use the JMODs bundles and not the artifacts
from Maven central. The maven modules are a handy convenience for
developers, but not recommend for creating packaged applications.
-- Kevin
On 11/16/2022 6:29 AM, Armin Schrenk wrote:
Hello,
for our application, a customer reported that the shared libraries
(in this case DLLs) used by JFX are unsigned and thus were blocked
from loading, which blocks the app from starting. The culprit for
blocking is a new security feature for Windows 11, Smart App Control
(https://support.microsoft.com/en-gb/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003).
Since this feature seems to be a future part of Windows, i suggest to
sign the shared libs before the maven release. In our case, the
archive javafx-graphics-*-win.jar contains the DLLs.
Apart from this feature request, we want to fix the issue on our
side. To do that, I investigated into the sharedLib loading of JFX.
SharedLib Loading is in JFX is done with the NativeLibLoader
(https://github.com/openjdk/jfx/blob/19+11/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java).
It does the following to load the native lib:
1. Load the DLLs from a certain path (see below)
2. On Failure, load the DLLs from a resource (aka the jar) by
extracting them to a cache directory and load them from there
3. On Failure, do other stuff not of interest
Our app is modular (or as much as possible), thus, the DLLs were
always loaded from the resource. But this extract-and-cache approach
is unsatisfying from our point of view. The app uses a custom JRE via
jlink and is packaged with jpackage, and we would like to place the
sharedLibs at build time somewhere in the app directory.
So I had to figure out the where to place the DLLs, or more
specifically, what path is checked in Step 1 of shared libLoading.
Reading the inline comment starting at line 117, it should be the
same dir as the jar is placed. Unfortunately, this is not the case
and i had to dig more through the code to find out.
Our app has the following structure:
|- JarsAndMods
| - Mods
| - modul1.jar
| - modul2.jar
| - ...
| - javafx-graphics-XXX-win.jar
| - ...
| - nonModular1.jar
| - nonModular2.jar
| - ...
|- executable
According to the comment, the path to place all DLLs should be
/JarsAndMods/Mods.
But verbose logging showed and later proofed by the code, it has to
be /JarsAndMods/bin.
My questions are:
Why does JFX require only for Windows the `../bin` directory?
Additionally, this inline comment has a FIXME that Step 1 of
SharedLibLoading should be removed in the future. Is there already an
ETA?
And lastly, I would love to see some Documentation for this. I can
write it and create the PR, but where should it be placed?
Best wishes,
Armin
