Jextract 20 binaries are now available
Duncan Gittins
duncan.gittins at gmail.com
Sat Apr 8 17:10:40 UTC 2023
Jorn
Thanks everyone for the effort on this. Its been a while since I've built
my own jextract v20 so your build has given me more recent changes.
Apologies if this is covered in previous trails: I have run into an issue
related to the way some performance changes were implemented in upcall stub
generation. The generated code has introduced new class loader dependencies
for Windows COM interfaces. For example using IShellLinkWVtbl gives rise to
many interfaces such as IShellLinkWVtbl$QueryInterface.
All is fine if use new jextract and perform my tests with generated file.
My arguments for jextract are:
--source -lshell32 -t duncan.win.shell --output source\duncan.win\java
headers\Shell32.h
where Shell32.h is just:
#include <shlobj_core.h>
However I've noticed the new jextract generated code has new class
dependencies. I lookup COM objects via IUnknown$QueryInterface and never
call the duplicate version like IShellLinkWVtbl$QueryInterface so I've been
striping these similar and un-used classes from my jars.
In the old code generation, IShellLinkWVtbl was independent of
IShellLinkWVtbl$QueryInterface and all other IXYZ COM interfaces.
The new generated code of IShellLinkWVtbl.java references
IShellLinkWVtbl$QueryInterface.class. Similarly every vtable class (eg
IUnknown / IPersistFile etc) depends now on every interface class file of
every COM interface (AddRef / Release / etc) it supports because of the new
xyz_UP$MH fields:
Exception java.lang.NoClassDefFoundError:
duncan/win/shell/IShellLinkWVtbl$QueryInterface
| at IShellLinkWVtbl.<clinit> (IShellLinkWVtbl.java:75)
Here is the snippet of new code which shows the new upcallHandle which
means every vtable.class requires all com .class files. I am hoping that
this can be resolved easily simply by generating the declaration of
QueryInterface_UP$MH inside interface IShellLinkWVtbl$QueryInterface rather
than into the parent class IShellLinkWVtbl. This would avoid a large number
of .class files being read when referencing a vtable class:
public class IShellLinkWVtbl {
...
static final MethodHandle QueryInterface_UP$MH =
RuntimeHelper.upcallHandle(QueryInterface.class, "apply",
IShellLinkWVtbl.QueryInterface_UP$FUNC);
...
/** HRESULT (*QueryInterface)(IShellLinkW*,const IID*,void**); */
public interface QueryInterface {
// UP$MH should be here?
int apply(java.lang.foreign.MemorySegment _x0,
java.lang.foreign.MemorySegment _x1, java.lang.foreign.MemorySegment _x2);
static MemorySegment allocate(QueryInterface fi, SegmentScope
scope) {
return
RuntimeHelper.upcallStub(IShellLinkWVtbl.QueryInterface_UP$MH, fi,
IShellLinkWVtbl.QueryInterface$FUNC, scope);
}
...
}
Kind regards
Duncan
On Fri, 7 Apr 2023 at 18:34, Jorn Vernee <jorn.vernee at oracle.com> wrote:
> Hello,
>
> Jextract 20 binaries are now available at: https://jdk.java.net/jextract/
>
> This version of jextract targets the foreign function and memory access
> API in Java 20, which was released recently as well [1]
>
> The existing binaries of jextract 19, which target Java 19, are still
> available through a link under the "Other versions" section on the
> jextract download page linked above.
>
> Jorn
>
> [1]: https://jdk.java.net/20/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20230408/0476d2ea/attachment.htm>
More information about the jextract-dev
mailing list