Feedback / query on jextract for Windows 10

[Maurizio Cimadamore]

On 23/01/2021 18:34, Duncan Gittins wrote:
> I've been using Panama on Windows 10 to eliminate my C# apps which I 
> would normally call via ProcessBuilder. I'm very impressed so far and 
> looking forward to newer versions: everything I have written in 
> Windows C# is now replaced with foreign memory / linker calls to 
> native code using the latest Java 16 EA.  I have examples for various 
> Win32 API and COM objects, HWND objects and screensaver. However I'm 
> struggling to get the code running with output from jextract build. 
> Perhaps I overlooked something very obvious in how to setup?
>
> One example app is attached - this calls SystemParametersInfoA to set 
> the Windows desktop background. There are two implementations of 
> setImage: one with hardwired MethodHandle works fine, but the jextract 
> version gives UnsupportedOperationException for layout unrelated to 
> SystemParametersInfoA. If I edit the generated code to comment out all 
> lines unrelated to SystemParametersInfoA then both versions of 
> setImage work.

I think the culprit is this:

```
Caused by: java.lang.UnsupportedOperationException: Invalid alignment 
requirements for layout 
b64(ArbitraryUserPointer)[abi/kind=POINTER,layout/name=ArbitraryUserPointer]
         at 
jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.checkAlignment(LayoutPath.java:273)
         at 
jdk.incubator.foreign/jdk.internal.foreign.LayoutPath.dereferenceHandle(LayoutPath.java:159)
         at 
jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.lambda$varHandle$2(MemoryLayout.java:488)
         at 
jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.computePathOp(MemoryLayout.java:534)
         at 
jdk.incubator.foreign/jdk.incubator.foreign.MemoryLayout.varHandle(MemoryLayout.java:488)
         at 
duncan.win32.shobjidl_core.shlobj_core_h$constants$16.<clinit>(shlobj_core_h$constants$16.java:1844)
```

This seems a duplicate of another issue that has been reported last week:

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

E.g. jextract ignoring alignment requirements. Note that jextract 
generates lots of constants, and it takes only one bad one to make 
initialization fail.

>
> The jextract command on Windows 10 (with fresh Vis Studio 
> installation) expands shlobj_core.h because I my app also uses 
> IShellLink.
>
>      set "WINKIT=c:\Program Files (x86)\Windows 
> Kits\10\Include\10.0.18362.0"
>      jextract --source -t duncan.win32.shobjidl_core -d 
> shlobj_core.h/java     "%WINKIT%/um/shlobj_core.h"
>
> Another issue is that this single windows header file gives rise to 
> 11MB jar and is unusable inside Eclipse (on my slow PC), and is slow 
> startup at runtime. Have you considered changing the generated code to 
> use lazy Supplier<MethodHandle> instead of MethodHandle to ensure only 
> required handles are created on-demand?

Uhm... we are already using dynamic constants, so you should only pay 
for the MHs and VHs you use - e.g. in fact I'm even surprised you get 
the failure inside the <clinit> above - since that constant should not 
be initialized unless it's used. I wonder if there's a regression 
here... are you using the `--source` flag? With that flag we revert back 
to a monolithic header, so that will explain both failures. If so, try 
removing that flag - and see what happens (if everything is working as 
it should I don't think you should even see the error above, assuming 
you never use that layout).

Maurizio

>
> Kind regards
>
> Duncan
>
>