<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 18/02/2024 08:53, Manuel
Bleichenbacher wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAA7F5jL45feKj72moz3SjSO5ykMOKDQNp9KLpB5JSpL7x6gHBw@mail.gmail.com">
<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>
</blockquote>
<p>Yes, that's the intended behavior. The alternatives are:</p>
<p>1. fail with error (as we try to do)<br>
2. issue warning and generate bad code<br>
3. issue warning and emit padding when the outer struct refers to
the nested missing struct<br>
4. do nothing (and generate bad code)<br>
</p>
<p>Before the changes, jextract used to do (4). Which means "your
mileage might vary". I don't think that's great, and we did get
some (internal) feedback that this was confusing. That said, while
looking at this, we considered both (3) and (1) - in the end we
opted for (1) because, if the user wants filtering, there might be
some value in making sure the filtering is set up correctly (e.g.
are we 100% sure that users are signing up for bad code or padding
- or maybe they just "missed" a dependency?)<br>
</p>
<p>We don't feel overly strong about this (mostly a mild
preference). Perhaps something that can be reassessed with more
feedback (after all the other issues have been fleshed out).</p>
<p>This behavior is documented in the README page:</p>
<p><a class="moz-txt-link-freetext" href="https://github.com/openjdk/jextract?tab=readme-ov-file#filtering-symbols">https://github.com/openjdk/jextract?tab=readme-ov-file#filtering-symbols</a></p>
<p>(see the end of this section). And, as Jorn said, these changes
are still not included in the binaries.<br>
</p>
<blockquote type="cite" cite="mid:CAA7F5jL45feKj72moz3SjSO5ykMOKDQNp9KLpB5JSpL7x6gHBw@mail.gmail.com">
<div dir="ltr">
<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>
</blockquote>
<p>We used to deal with this fine, but the code for emitting
struct/union layouts has changed a lot (as a result of attempting
to refer to struct/union by name). It seems like a new bug w.r.t.
alignment has crept in. I will take a look. The way it _should_
work is that we should get the offset info from libclang, and then
add "withAlignment" accordingly, to make sure the struct layout
can be built.<br>
</p>
<p>Maurizio<br>
</p>
<blockquote type="cite" cite="mid:CAA7F5jL45feKj72moz3SjSO5ykMOKDQNp9KLpB5JSpL7x6gHBw@mail.gmail.com">
<div dir="ltr">
<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" 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>
</body>
</html>