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

[Maurizio Cimadamore]

Hi Duncan,
thanks for the workaround.

This is obviously fine for now, but IMHO, system lookup should never 
throw, regardless of the environment.

Maurizio

On 07/02/2022 13:44, Duncan Gittins wrote:
> 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