jextract generated code

[Duncan Gittins]

I've been using jextract for some time now, it has saved a great deal of
effort in enabling some Windows features within my Java applications. Thank
you to everyone involved.

I've a few (trivial) observations on the generated code which have puzzled
me, perhaps they are already addressed with work in the pipeline:

1) RuntimeHelper.java - downcallHandle(String name, FunctionDescriptor
fdesc, boolean variadic).  The isVariadic flag is known at generate time
(for my case), so why is this flag passed in for runtime evaluation instead
of generating a call directly to a variadic-only downcall handler ?
2) RuntimeHelper.java looks like it should be a pure support class but it
contains generated code. This makes it difficult to swap out with a
compatible version, say one with project specific logging classes. Any
reason why not move the System.loadLibrary() calls to a fully generated
class such as Constants$root.java (which appears to be referenced before
RuntimeHelper is used)? If building a project jar from multiple jextract
runs there are multiple RuntimeHelper+VariadicInvoker per project jar so
avoiding System.loadLibrary() would also make it easier to plan for a
single definition of these support classes.
3) Generated header file classes - XYZ_h.java    Below is a fragment of
generated code for Windows OLE library  (-lole32 --include-function
CoCreateInstance with XYZ.h "#include <objbase.h>"). Is there a reason to
duplicate requireNonNull(xxxx$MH) calls, when instead CoCreateInstance()
could just call CoCreateInstance$MH() ?

public static MethodHandle CoCreateInstance$MH() {
return
RuntimeHelper.requireNonNull(constants$2.CoCreateInstance$MH,"CoCreateInstance");
}
public static int CoCreateInstance ( Addressable rclsid,  Addressable
pUnkOuter,  int dwClsContext,  Addressable riid,  Addressable ppv) {
var mh$ = RuntimeHelper.requireNonNull(constants$2.CoCreateInstance$MH,
"CoCreateInstance");
...
}

Kind regards

Duncan