Fwd: jextract / jpackage / JavaFX - Windows library load issue

[Duncan Gittins]

The jpackage / JavaFX issue sounds like the one I reported in May - see 
below. There is a workaround - depending on which Panama version you are 
using - by editing the RuntimeHelper.lookup() call to eliminate the 
CLinker.systemLookup(). This might introduce other issues, but did not 
affect my own jextract / jpackage / JavaFX app.

https://bugs.openjdk.java.net/browse/JDK-8281335

I don't apply this workaround now for RuntimeHelper of my JavaFX / 
jpackage app - not sure if bug still applies, I will scan my source 
code. Also note earlier versions of jpackage messed up library path on 
Windows.

Kind regards

Duncan

-------- Forwarded Message --------
Subject: 	jextract / jpackage / JavaFX - Windows library load issue
Date: 	Sat, 22 May 2021 13:34:25 +0100
From: 	Duncan Gittins <duncan.gittins at gmail.com>
To: 	panama-dev at openjdk.java.net



It's great to see you've released a new Panama/foreign EA - much 
appreciated. Here is some feedback which I noticed in EA and latest 
panama-foreign for a recent change in behaviour when using jextract / 
jpackage together for a JavaFX application.

I use jextract on 5 headers - one package per Windows library (Ole32_h / 
Shell32 / User / Kernel32 / Advapi). My different app runs fine from 
command line with "java", but the same jars+runtime inside jpackage EXE 
always gives library load errors for jextract code called by a JavaFX app:

Caused by: java.lang.UnsatisfiedLinkError: Native Library 
C:\Windows\System32\ucrtbase.dll already loaded in another classloader

         ...
         at 
jdk.incubator.foreign/jdk.incubator.foreign.CLinker.systemLookup(Unknown 
Source)
         at duncan.win.ole.RuntimeHelper.lookup(RuntimeHelper.java:50)
         at duncan.win.ole.Ole32_h.<clinit>(Ole32_h.java:16)
         at duncan.panama.Ole32.CoInitialize(Unknown Source)

Non-JavaFX apps using jextract code all run fine as EXE. My easy 
workaround is to hand edit 5x RuntimeHelper.lookup() to omit use of 
"systemLookup":

     static SymbolLookup lookup() {
         SymbolLookup loaderLookup = SymbolLookup.loaderLookup();
         // THIS LINE CAUSES UnsatisfiedLinkError: SymbolLookup 
systemLookup = CLinker.systemLookup();
         return name -> loaderLookup.lookup(name) /*.or(() -> 
systemLookup.lookup(name)) */;
     }

Do you have suggestions on what I should be doing? If nothing obvious, 
and as I've not given much detail on reproducing this issue, I could try 
to set up a minimal test case to help with further investigations.

BTW I mentioned in different thread a few weeks ago that jpackage has 
changed between JDK16 and JDK17. New jpackage strips the Windows default 
library path from java.library.path,
so you have to add "--java-options 
-Djava.library.path=c:\\Windows\\System32" to allow jpackage to run any 
Panama code as Windows EXE. The library load error as above appears in 
EXEs generated by both versions of jpackage.

Kind regards

Duncan