<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Thanks for the reports Manuel.</p>
<p>It seems to me that the very-recently-introduced feature to catch
broken dependencies needs some more ironing out (understandable,
as it's just fresh out of the press).</p>
<p>Overall, you seem to have reported the following issues:</p>
<p>* spurious missing dependency errors for stuff that is not
generated anyway (e.g. missing struct depends on another missing
struct)<br>
* no error generated for missing dependencies in array types<br>
* NullPointerException when creating enum constants (it seems like
jextract here is returning a null declaration tree for an enum
constant... seems a very odd situation).<br>
* Bad alignment when creating layouts for packed structs</p>
<p>Is this list correct? Of these, it seems to me the latter two are
more important to fix, as they are clear regression in behavior.
The first two seem more (perhaps annoying) "quality of life"
issues with a newly introduced feature.</p>
<p>Cheers<br>
Maurizio<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 18/02/2024 09:00, Manuel
Bleichenbacher wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAA7F5j+Em1-uVS1=JWLyy1pp-oT_YbBLz87VF6X07iiyQMTT7g@mail.gmail.com">
<div dir="ltr">
<div>With regards to "struct udev". I very much support your
last comment that this should work without warnings.</div>
<div><br>
</div>
<div>"struct udev" is an opaque data structure. The API only
uses pointers to the struct but never reveals its actual
layout as it is an implementation detail and can change from
version to version. This is an established and good pattern.
And jextract should be able to handle it.</div>
<div><br>
</div>
<div>Regards</div>
<div>Manuel</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Am So., 18. Feb. 2024 um
09:53 Uhr schrieb Manuel Bleichenbacher <<a href="mailto:manuel.bleichenbacher@gmail.com" moz-do-not-send="true" class="moz-txt-link-freetext">manuel.bleichenbacher@gmail.com</a>>:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>Hi Jorn</div>
<div><br>
</div>
<div>Regarding the dependencies: Do I get it correctly? If a
struct, e.g. epoll_event, includes another struct, e.g.
epoll_data, I have to explicitly include both of them?</div>
<div><br>
</div>
<div>If this is the case, it's a bit annoying but doable. It
should probably be better documented (or did I miss the
documentation of this fact)?</div>
<div><br>
</div>
<div>Anyhow, it leads to the next issue (likely a bug or
limitation of jextract) with the generated code for
epoll_event and epoll_data (from <sys/epoll.h>).
When the generated class epoll_event is accessed for the
first time, it crashes with:</div>
<div><br>
</div>
<div>Caused by: java.lang.IllegalArgumentException: Invalid
alignment constraint for member layout:
[a8(ptr):[*:b1]|i4(fd)|i4(u32)|j8(u64)](data)<br>
at
java.base/jdk.internal.foreign.layout.StructLayoutImpl.of(StructLayoutImpl.java:49)<br>
at
java.base/java.lang.foreign.MemoryLayout.lambda$structLayout$1(MemoryLayout.java:1063)<br>
at
java.base/jdk.internal.foreign.Utils.wrapOverflow(Utils.java:277)<br>
at
java.base/java.lang.foreign.MemoryLayout.structLayout(MemoryLayout.java:1062)<br>
at
net.codecrete.usb/net.codecrete.usb.linux.gen.epoll.epoll_event.<clinit>(epoll_event.java:29)<br>
</div>
<div><br>
</div>
<div>epoll_event is a tricky structure. It looks like so:</div>
<div><br>
</div>
<div>typedef union epoll_data<br>
{<br>
void *ptr;<br>
int fd;<br>
uint32_t u32;<br>
uint64_t u64;<br>
} epoll_data_t;<br>
<br>
struct epoll_event<br>
{<br>
uint32_t events;<br>
epoll_data_t data;<br>
} __EPOLL_PACKED;</div>
<div><br>
</div>
<div>Because it's packed, the fields data.ptr and data.u64
are not aligned.</div>
<div><br>
</div>
<div>It can be made to work if epoll_data.ptr and
epoll_data.u64 are set to a byte alignment of 4. But
that's not actually correct. epoll_data is not a packed or
unaligned struct. It's only unaligned if used within
another packed struct.</div>
<div><br>
</div>
<div>Regards</div>
<div>Manuel</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Am So., 18. Feb. 2024 um
09:34 Uhr schrieb Manuel Bleichenbacher <<a href="mailto:manuel.bleichenbacher@gmail.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">manuel.bleichenbacher@gmail.com</a>>:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Hi Jorn
<div><br>
</div>
<div>Thanks for the prompt response. Using the pre-built
binaries, I've made some progress on Linux but run
into new issues. I will provide the feedback one by
one.</div>
<div><br>
</div>
<div>So let's start with the macOS. Here's the output
run with verbose.</div>
<div><br>
</div>
<div>I also propose to suppress the unrelated warning
that occurs on all platforms. It's just annoying. And
it will send newcomers in the wrong direction when
they actually have to investigate real warnings or
errors.</div>
<div><br>
</div>
<div>Regards</div>
<div>Manuel</div>
<div> </div>
<div><br>
</div>
<div>WARNING: A restricted method in
java.lang.foreign.AddressLayout has been called<br>
WARNING:
java.lang.foreign.AddressLayout::withTargetLayout has
been called by
org.openjdk.jextract.clang.libclang.Index_h in module
org.openjdk.jextract<br>
WARNING: Use
--enable-native-access=org.openjdk.jextract to avoid a
warning for callers in this module<br>
WARNING: Restricted methods will be blocked in a
future release unless native access is enabled<br>
<br>
Cannot invoke
"org.openjdk.jextract.Declaration$Constant.name()"
because "<parameter2>" is null<br>
java.lang.NullPointerException: Cannot invoke
"org.openjdk.jextract.Declaration$Constant.name()"
because "<parameter2>" is null<br>
at
<a class="moz-txt-link-abbreviated" href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.impl.TreeMaker.enumConstantString">org.openjdk.jextract@22/org.openjdk.jextract.impl.TreeMaker.enumConstantString</a>(TreeMaker.java:532)<br>
at
<a class="moz-txt-link-abbreviated" href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.impl.TreeMaker.lambda$createEnum$7">org.openjdk.jextract@22/org.openjdk.jextract.impl.TreeMaker.lambda$createEnum$7</a>(TreeMaker.java:375)<br>
at
java.base/java.util.ArrayList.forEach(ArrayList.java:1597)<br>
at
<a class="moz-txt-link-abbreviated" href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.impl.TreeMaker.createEnum">org.openjdk.jextract@22/org.openjdk.jextract.impl.TreeMaker.createEnum</a>(TreeMaker.java:373)<br>
at
<a class="moz-txt-link-abbreviated" href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.impl.TreeMaker.createTreeInternal">org.openjdk.jextract@22/org.openjdk.jextract.impl.TreeMaker.createTreeInternal</a>(TreeMaker.java:133)<br>
at
<a class="moz-txt-link-abbreviated" href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.impl.TreeMaker.createTree">org.openjdk.jextract@22/org.openjdk.jextract.impl.TreeMaker.createTree</a>(TreeMaker.java:119)<br>
at
<a class="moz-txt-link-abbreviated" href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.impl.Parser.lambda$parse$2">org.openjdk.jextract@22/org.openjdk.jextract.impl.Parser.lambda$parse$2</a>(Parser.java:86)<br>
at
<a class="moz-txt-link-abbreviated" href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor$CursorChildren.lambda$forEach$1">org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor$CursorChildren.lambda$forEach$1</a>(Cursor.java:261)<br>
at
<a class="moz-txt-link-abbreviated" href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor$CursorChildren$Context.visit">org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor$CursorChildren$Context.visit</a>(Cursor.java:234)<br>
at
<a class="moz-txt-link-abbreviated" href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor$CursorChildren.lambda$static$0">org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor$CursorChildren.lambda$static$0</a>(Cursor.java:252)<br>
at
<a class="moz-txt-link-abbreviated" href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.Index_h.clang_visitChildren">org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.Index_h.clang_visitChildren</a>(Index_h.java:8275)<br>
at
<a class="moz-txt-link-abbreviated" href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor$CursorChildren.forEachShortCircuit">org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor$CursorChildren.forEachShortCircuit</a>(Cursor.java:271)<br>
at
<a class="moz-txt-link-abbreviated" href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor$CursorChildren.forEach">org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor$CursorChildren.forEach</a>(Cursor.java:260)<br>
at
<a class="moz-txt-link-abbreviated" href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor.forEach">org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor.forEach</a>(Cursor.java:201)<br>
at
<a class="moz-txt-link-abbreviated" href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.impl.Parser.parse">org.openjdk.jextract@22/org.openjdk.jextract.impl.Parser.parse</a>(Parser.java:64)<br>
at
<a class="moz-txt-link-abbreviated" href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.JextractTool.parse">org.openjdk.jextract@22/org.openjdk.jextract.JextractTool.parse</a>(JextractTool.java:119)<br>
at
<a class="moz-txt-link-abbreviated" href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.JextractTool.run">org.openjdk.jextract@22/org.openjdk.jextract.JextractTool.run</a>(JextractTool.java:516)<br>
at
<a class="moz-txt-link-abbreviated" href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.JextractTool.main">org.openjdk.jextract@22/org.openjdk.jextract.JextractTool.main</a>(JextractTool.java:218)<br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Am Sa., 17. Feb. 2024
um 20:46 Uhr schrieb Jorn Vernee <<a href="mailto:jorn.vernee@oracle.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">jorn.vernee@oracle.com</a>>:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>One more thing I realized about the warnings you
get for /usr/include/libudev.h: the structs about
which you get warnings are not being included
(looking at your script, there are no
--include-struct for them), so there shouldn't be
any need for us to warn about them either.</p>
<p>We currently check whether things are included
first, and then mark things that aren't as
'skipped'. However, in the later pass which checks
for unsupported types, we also issue warnings for
those skipped elements. I think we should just
skip issuing warnings for things that are marked
as skipped by the earlier pass.<br>
</p>
<p>Jorn<br>
</p>
<div>On 17/02/2024 17:59, Jorn Vernee wrote:<br>
</div>
<blockquote type="cite">
<p>Hey Manuel,</p>
<p>Thanks for giving jextract 22 a try, and sorry
for the frustrating experience.</p>
<p>- The <font face="monospace">NullPointerException
</font>is definitely a bug. Jextract should not
just report an exception. We'll have a closer
look at this on Monday, and see if we can find
what code causes the issue. It would help if you
could edit the jextract launch script, and add
`JLINK_VM_OPTIONS=-Djextract.debug=true`
(`JLINK_VM_OPTIONS=` should already be there),
and then retry the failed extraction. This
should print out more information, including the
entire stack trace. that's the part I'm
interested in.<br>
<br>
<br>
> I don't understand the error message. What
does "xxx depends on yyy which has been
excluded" mean? Have I used it incorrectly? The
error message mostly mentions types (and
possibly functions) that I don't use, neither
directly nor indirectly. </p>
<p>It is meant to tell the user that they've
included something that depends on something
else which was not included. This would
previously lead to uncompileable code, since
FunctionDescriptors and MemoryLayouts now refer
directly to the layouts defined in struct
classes. For example, if I have a function like
`void foo(struct A)`, then the
FunctionDescriptor for `foo` will depend
directly on the class we generate for `struct
A`:<br>
<font face="monospace"><br>
FunctionDescriptor.ofVoid(<br>
A.layout()<br>
);</font></p>
<p>If `A` itself is not included, this code would
be uncompileable. So, in the latest version we
(try to) issue an error about that.</p>
<p>- For the 'ERROR's due to missing dependencies
you are seeing: this also looks like a bug. We
are currently issuing errors if a _skipped_
symbols depends on a skipped symbol as well,
which makes no sense. We can just ignore missing
dependencies of skipped things. I've tried to
implement a quick fix here [1]. Though, you
might be better off using the pre-built binaries
for now, which don't have this dependency
scanning behavior in the first place (i.e the
builds at <a href="http://jdk.java.net/jextract" target="_blank" moz-do-not-send="true">jdk.java.net/jextract</a>)<br>
<br>
<br>
> And why are udev, udev_list_entry,
udev_device etc. skipped? They used to work with
jextract 21.</p>
<p>- I took a look at libudev.h, and the warnings
about unsupported types seem correct to me. e.g.
`struct udev` does not have a definition in
libudev.h [2], so jextract can not generate a
class for it (since the layout and fields are
not known). That is all the the warning is
trying to say. The other structs about which you
get a warning seems to be the same in that they
don't have a definition in that file. (FWIW this
is one of the areas we put a lot of effort into,
so it makes sense that you didn't seen a warning
in JDK 21). I think we need to clarify the error
message to say more than "is not supported"
though.<br>
<br>
<br>
> /usr/include/linux/usbdevice_fs.h: The code
generated for the struct usbdevfs_urb does not
compile (it refers to a
type usbdevfs_iso_packet_desc, which is
missing).</p>
<p>This is actually the situation we were trying
to detect with the ERRORs you encountered. There
should have been an error about <font face="monospace">usbdevfs_iso_packet_desc</font>
being excluded, but it seems like we are not
scanning the element types of arrays at the
moment (linked PR tries to fix this as well).<br>
<br>
<br>
And finally, yeah: we need to update the README
on the master branch to reference JDK 22 instead
of 21.<br>
</p>
<p>Thanks for reporting back! While we try to test
as much as possible, some issues slip through
the cracks, and are only found through user
feedback like yours.<br>
Jorn<br>
</p>
<p>[1]: <a href="https://github.com/openjdk/jextract/pull/217" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openjdk/jextract/pull/217</a><br>
[2]: <a href="https://github.com/systemd/systemd/blob/main/src/libudev/libudev.h#L20C1-L20C13" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/systemd/systemd/blob/main/src/libudev/libudev.h#L20C1-L20C13</a><br>
</p>
<div>On 17/02/2024 15:40, Manuel Bleichenbacher
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">Hi Maurizio
<div><br>
</div>
<div>I have tried to upgrade the JavaDoesUSB
library (<a href="https://github.com/manuelbl/JavaDoesUSB" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/manuelbl/JavaDoesUSB</a>)
from JDK 21 to 22, and it was very
frustrating. It failed on macOS, Windows
nor Linux. And the problem is jextract.</div>
<div><br>
</div>
<div>(The header files I'm trying the
process are operating system header
files.)</div>
<div><br>
</div>
<div><br>
</div>
<div>On macOS, it always crashes:</div>
<div><br>
</div>
<div>FATAL: Unexpected exception
java.lang.NullPointerException: Cannot
invoke
"org.openjdk.jextract.Declaration$Constant.name()"
because "<parameter2>" is null
occurred<br>
</div>
<div><br>
</div>
<div>I've tried different branches (master,
panama, jdk22) and the pre-built binaries.
They all behave the same except the error
message is sometimes shorter and starts at
"Cannot invoke..."</div>
<div><br>
</div>
<div>The full commands can be found here
(remove "--source"): <a href="https://github.com/manuelbl/JavaDoesUSB/blob/main/java-does-usb/jextract/macos/gen_macos.sh" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/manuelbl/JavaDoesUSB/blob/main/java-does-usb/jextract/macos/gen_macos.sh</a></div>
<div><br>
</div>
<div><br>
</div>
<div>On Linux, jextract worked partially.
But for several files, it refused to
generate anything or generated code that
didn't compile:</div>
<div><br>
</div>
<div>/usr/include/fcntl.h:</div>
<div>ERROR: stat depends on timespec which
has been excluded<br>
ERROR: stat depends on timespec which has
been excluded<br>
ERROR: stat depends on timespec which has
been excluded<br>
</div>
<div><br>
</div>
<div>/usr/include/libudev.h:</div>
<div>ERROR: __pthread_list_t depends on
__pthread_internal_list which has been
excluded<br>
ERROR: __pthread_slist_t depends on
__pthread_internal_slist which has been
excluded<br>
ERROR: __pthread_mutex_s depends on
__pthread_internal_list which has been
excluded<br>
WARNING: Skipping va_list (type <error:
struct __va_list_tag> is not supported)<br>
WARNING: Skipping __gnuc_va_list (type
<error: struct __va_list_tag> is not
supported)<br>
WARNING: Skipping udev (type
Declared(udev) is not supported)<br>
WARNING: Skipping udev_list_entry (type
Declared(udev_list_entry) is not
supported)<br>
WARNING: Skipping udev_device (type
Declared(udev_device) is not supported)<br>
WARNING: Skipping udev_monitor (type
Declared(udev_monitor) is not supported)<br>
WARNING: Skipping udev_enumerate (type
Declared(udev_enumerate) is not supported)<br>
WARNING: Skipping udev_queue (type
Declared(udev_queue) is not supported)<br>
WARNING: Skipping udev_hwdb (type
Declared(udev_hwdb) is not supported)<br>
</div>
<div><br>
</div>
<div>sys/epoll.h:</div>
<div>ERROR: __pthread_list_t depends on
__pthread_internal_list which has been
excluded<br>
ERROR: __pthread_slist_t depends on
__pthread_internal_slist which has been
excluded<br>
ERROR: __pthread_mutex_s depends on
__pthread_internal_list which has been
excluded<br>
ERROR: epoll_data_t depends on epoll_data
which has been excluded<br>
ERROR: epoll_event depends on epoll_data
which has been excluded<br>
</div>
<div><br>
</div>
<div>/usr/include/linux/usbdevice_fs.h:<br>
</div>
<div>The code generated for the
structusbdevfs_urb does not compile (it
refers to a type usbdevfs_iso_packet_desc,
which is missing).</div>
<div><br>
</div>
<div>The full commands for jextract can be
found here. I've only removed "--source"
as it is no longer needed.</div>
<div><a href="https://github.com/manuelbl/JavaDoesUSB/blob/main/java-does-usb/jextract/linux/gen_linux.sh" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/manuelbl/JavaDoesUSB/blob/main/java-does-usb/jextract/linux/gen_linux.sh</a><br>
</div>
<div><br>
</div>
<div>All these files could successfully be
processed with jextract 21.</div>
<div><br>
</div>
<div>I don't understand the error message.
What does "xxx depends on yyy which has
been excluded" mean? Have I used it
incorrectly? The error message mostly
mentions types (and possibly functions)
that I don't use, neither directly nor
indirectly.</div>
<div><br>
</div>
<div>And why are udev, udev_list_entry,
udev_device etc. skipped? They used to
work with jextract 21.</div>
<div><br>
</div>
<div><br>
</div>
<div>On Windows, it completely failed as
well. jextract outputs more than 5000
lines of errors and warnings. Here is just
a random selection:</div>
<div><br>
</div>
<div>ERROR: mbstate_t depends on _Mbstatet
which has been excluded<br>
</div>
<div>ERROR: LIST_ENTRY depends on
_LIST_ENTRY which has been excluded<br>
</div>
<div>ERROR: depends on _M128A which has
been excluded<br>
</div>
<div>ERROR: WIN32_FIND_STREAM_DATA depends
on _WIN32_FIND_STREAM_DATA which has been
excluded<br>
</div>
<div>ERROR: tagEXTLOGFONTW depends on
tagLOGFONTW which has been excluded<br>
</div>
<div>ERROR: MULTIKEYHELPW depends on
tagMULTIKEYHELPW which has been excluded<br>
</div>
<div>WARNING: Skipping
MEM_EXTENDED_PARAMETER.Reserved (bitfields
are not supported)<br>
</div>
<div>WARNING: Skipping Flags.Reserved
(bitfields are not supported)<br>
</div>
<div><br>
</div>
<div>The full command can be found here
(remove "--source"): <a href="https://github.com/manuelbl/JavaDoesUSB/blob/main/java-does-usb/jextract/windows/gen_win.cmd" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/manuelbl/JavaDoesUSB/blob/main/java-does-usb/jextract/windows/gen_win.cmd</a></div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>The REAMDE on <a href="https://github.com/openjdk/jextract" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openjdk/jextract</a>
could also profit from an update:</div>
<div><br>
</div>
<div>The command line "$ sh ./gradlew
-Pjdk21_home=<jdk21_home_dir> ..."
sent me on search for the branch with the
JDK 22 code. But it's just the README
that's outdated.</div>
<div><br>
</div>
<div>And the instruction "Run the Gradle
build with a Java version appropriate for
the Gradle version. For example, Gradle
7.5.1 supports JDK 21." sent me down
another rabbit hole. I have the latest
Gradle version installed, which nicely
runs with JDK 21. But it failed anyway.
Turns out that the installed gradle is
irrelevant but the gradle wrapper relevant
(see command line above). And the gradle
wrapper is at version 7.3.3. So there is
nothing to choose really. You must use JDK
17 (or even earlier). It has never worked
with JDK 21.</div>
<div><br>
</div>
<div><br>
</div>
<div>I would appreciate some feedback. Are
these bugs? Or has jextract become so much
more restrictive?</div>
<div><br>
</div>
<div>Regards</div>
<div>Manuel</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Am Fr.,
16. Feb. 2024 um 16:50 Uhr schrieb
Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">maurizio.cimadamore@oracle.com</a>>:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
with JDK 22 near us, we have spent some
quality time with jextract, to <br>
make sure the code it generates is as good
as it can be ahead of the <br>
finalizaton of the FFM API. This resulted
in several changes, both in <br>
the implementation (so, invisible to
jextract users) and in the <br>
generated code, as we cleaned up the
translation strategy to better <br>
adhere with the core principles behind the
jextract tool. These changes <br>
are captured in details in this document:<br>
<br>
<a href="https://cr.openjdk.org/~mcimadamore/panama/jextract_changes.html" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://cr.openjdk.org/~mcimadamore/panama/jextract_changes.html</a><br>
<br>
It might be a good time to take the latest
jextract for a spin (using <br>
your favourite C library!) and report
back, in case we missed anything. <br>
You can find the latest sources in this
branch:<br>
<br>
<a href="https://github.com/openjdk/jextract/tree/panama" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openjdk/jextract/tree/panama</a><br>
<br>
Binary snapshots of this newer version are
also available here (note <br>
that MacOS/Arm64 builds is also supported
now):<br>
<br>
<a href="https://jdk.java.net/jextract/" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://jdk.java.net/jextract/</a><br>
<br>
Cheers<br>
Maurizio<br>
<br>
</blockquote>
</div>
</div>
</blockquote>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>