Signing shared libraries and questions about loading

[Armin Schrenk]

A solution via dependency management would be great, indeed.

But since the problem at hand needs to be fixed, for now we are rolling 
with the "duck tape" build. I have follow-up question on that:

We want to add a guard to our CI, checking that the JavaFX version in 
the POM and the JavaFx version in the jmods are always the same. 
Extracting the javafx version from the pom is easy, but for the jmods 
there is no apparent way. After looking into the JMODS, i found the file 
javafx.base.jmod/lib/javafx.properties which contains the JFX version. 
Also looking at the JDK bug tracker, this file is mentioned in several 
tickets. Can I rely on this file or is it "for internal use" only and 
can change anytime?

Best wishes,

Armin

Am 21/11/2022 um 22:59 schrieb Scott Palmer:
> This is why I suggested long ago that there should be .jmod zips in Maven central or similar.  We need a dependency management system that works with JMODs for exactly this reason. Zips in the current public repos would work.
>
> Scott
>
>> On Nov 21, 2022, at 11:08 AM, Armin Schrenk<armin.schrenk at skymatic.de>  wrote:
>>
>> 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
>>>>