Signing shared libraries and questions about loading

[Armin Schrenk]

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