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<[email protected]> 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
