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