Signing shared libraries and questions about loading
Kevin Rushforth
kevin.rushforth at oracle.com
Wed Nov 16 14:39:42 UTC 2022
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
>
More information about the openjfx-dev
mailing list