December 2025 - jextract-dev

RFR: 7904115: Fix for AIX test case failures due to incorrect alignment for double and pointer
by Varada M 18 Feb '26

18 Feb '26

Total of 10 test failures observed on AIX: jtreg/generator/nestedTypes/TestNestedTypesUnsupported.java jtreg/generator/test8246400/LibTest8246400Test.java jtreg/generator/test8258605/LibTest8258605Test.java jtreg/generator/test8261511/Test8261511.java jtreg/generator/testStruct/LibStructTest.java testng/org/openjdk/jextract/test/toolprovider/ConstantsTest.java testng/org/openjdk/jextract/test/toolprovider/IncompleteArrayTest.java testng/org/openjdk/jextract/test/toolprovider/Test8240811.java testng/org/openjdk/jextract/test/toolprovider/TestClassGeneration.java testng/org/openjdk/jextract/test/toolprovider/nestedAnonOffset/TestNestedAnonOffset.java This PR fixes AIX specific layout generation issues related to incorrect alignment double and pointer types. 1. Structs containing double fields fail with: i. Unsupported layout: 4%D8 ii. Invalid alignment constraint for member layout double in AIX structs has size 8 but alignment 4 (except as first field). AIX specific handling for C_DOUBLE computes the correct alignment. 2. Clang was detected as 32-bit due to missing -m64 during macro extraction, causing inconsistent macros. This caused jextract to interpret pointer constants incorrectly, leading to failures like: expected [-1] but found [4294967295] 3. TestNestedAnonOffset.java test failed on AIX because it also expects more padding similar to platforms like windows and linux After the patch jtreg tests passes successfully. JBS: [CODETOOLS-7904115](https://bugs.openjdk.org/browse/CODETOOLS-7904115) ------------- Commit messages: - testcase fixes for aix - testcase fixes for aix - testcase fixes for aix - testcase fixes for aix Changes: https://git.openjdk.org/jextract/pull/296/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=296&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904115 Stats: 27 lines in 6 files changed: 24 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jextract/pull/296.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/296/head:pull/296 PR: https://git.openjdk.org/jextract/pull/296

5 46

jextract cannot generate portable code (anymore)
by some-java-user-99206970363698485155＠vodafonemail.de 27 Jan '26

27 Jan '26

Hello, the jextract guide [1] says that jextract can generate portable code if the C code on which it is executed is portable. That seems to be no longer the case due to https://bugs.openjdk.org/browse/CODETOOLS-7903923. There are two problems: * On Windows it generates `OfInt C_LONG`, on non-Windows `OfLong C_LONG`. But it looks up the layout dynamically using `canonicalLayouts().get(...)`. Regardless of whether the generated code actually uses `C_LONG` you will get a ClassCastException during initialization when trying for example to use code generated on Linux on a Windows machine: "ClassCastException: class jdk.internal.foreign.layout.ValueLayouts$OfIntImpl cannot be cast to class java.lang.foreign.ValueLayout$OfLong" * The general approach of using `canonicalLayouts().get(...)` seems to make this non-portable (even if the code declared `C_LONG` as the general `ValueLayout` instead of the specific `OfInt` / `OfLong`, avoiding the ClassCastException), because jextract converts types such as `size_t` and `int64_t` to `C_LONG` on Linux, even though these types are defined in `canonicalLayouts()` as well. Take for example https://github.com/tree-sitter/java-tree-sitter/blob/master/scripts/jextrac… which runs jextract for https://github.com/tree-sitter/tree-sitter/blob/master/lib/include/tree_sit… Note that `api.h` is (if I see it correctly) portable. However for `int64_t` (used by `ts_tree_cursor_goto_first_child_for_byte`) jextract uses the non-portable `C_LONG` on Linux. Another problem are `calloc` and `malloc` where jextract treats `size_t` as non-portable `C_LONG` as well (I guess `size_t` would be portable at least across 64 bit platforms, or would fail with a ClassCastException if not, as desired). jextract version: Build 25-jextract+2-4 (2025/11/25) Note sure what a good solution to this is. Maybe an opt-out CLI flag for the CODETOOLS-7903923 behavior, and an update to GUIDE.md? That would make code generated with jextract on Linux portable to Windows again I think. Or are there cases where CODETOOLS-7903923 is really needed (even for portable C libraries)? Or a way for jextract to not convert `int64_t` and `size_t` to C_LONG, if that is possible? Or is there possibly also a problem with the https://github.com/tree-sitter/java-tree-sitter setup mentioned above? For example is there a way to make jextract refer to `int64_t` in the generated code instead of `C_LONG`? Kind regards [1] https://github.com/openjdk/jextract/blob/b96ad6618a70ddbdf6b67cc3eb8342efc3…

3 5

RFR: 7904120: Update jcheck configuration to allow more tags
by Nizar Benalla 12 Dec '25

12 Dec '25

Please review this PR to allow the use of release tags such as `jextract-25+4` ------------- Commit messages: - permit more tags Changes: https://git.openjdk.org/jextract/pull/298/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=298&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904120 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jextract/pull/298.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/298/head:pull/298 PR: https://git.openjdk.org/jextract/pull/298

4 6

RFR: Add support for AIX in build process
by Suchismith Roy 11 Dec '25

11 Dec '25

Summary of the issues: 1. There is no support for compiling AIX dynamic .a library and the tool was compiling .so files instead. 2. There is no logic to support libclang.a. 3. There is no support to load shared member of .a dynamic libraries of AIX. JBS Issue: [CODETOOLS-7904116](https://bugs.openjdk.org/browse/CODETOOLS-7904116) ------------- Commit messages: - remove executable - remove extra changes - library loading logic - build file changes - gradle fixes - jextract: Cleanup of Index_h - cmake support - jextract: Enable loading of dynamic archives for AIX Changes: https://git.openjdk.org/jextract/pull/297/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=297&range=00 Stats: 416 lines in 7 files changed: 113 ins; 273 del; 30 mod Patch: https://git.openjdk.org/jextract/pull/297.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/297/head:pull/297 PR: https://git.openjdk.org/jextract/pull/297

3 39

RFR: 7904089: jextract cannot handle "void foo(int foo)"
by Nizar Benalla 11 Dec '25

11 Dec '25

Please review this change to fix a name conflicts between functions and name parameters. TIA! ------------- Commit messages: - handle name conflicts Changes: https://git.openjdk.org/jextract/pull/292/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=292&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904089 Stats: 117 lines in 4 files changed: 116 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jextract/pull/292.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/292/head:pull/292 PR: https://git.openjdk.org/jextract/pull/292

3 4

Release frequency for binaries
by Adrian Trapletti 01 Dec '25

01 Dec '25

Hi, I am wondering what is the release frequency or strategy for jextract binaries, in particular e.g. after a bug like https://github.com/openjdk/jextract/commit/91fc954c46fac907cae6cd1417d83520… has been detected and fixed, are you going to provide a new binary release? Best, Adrian *Dr. Adrian Trapletti* CEO *Uster Metrics GmbH *| Steinstrasse 9b, 8610 Uster, Switzerland P +41 32 512 83 63 | M +41 79 103 71 31 a.trapletti(a)ustermetrics.com | www.ustermetrics.com This email message including any attachments is confidential and may be privileged. It is intended solely for the use of the individual or entity named on this message. It is provided for informational purposes only and does not constitute an offer or invitation to subscribe for or purchase any services or products. Any form of disclosure, copying, modification or distribution is unauthorized. If you are not the intended recipient, you are requested to please notify the sender immediately and delete the message including any attachments from your computer system network. Email transmission cannot be guaranteed to be secure or error free as information could be modified. We therefore do not accept responsibility or liability as to the completeness or accuracy of the information contained in this message or any attachments.

3 3