January 2026 - 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

Transcription of documentation comments to generated bindings
by jextract＠xpple.dev 23 Jan '26

23 Jan '26

Hello, I have been using jextract for a while now, and my experience has been great overall. The only thing that bothered me when using the generated bindings was their lack of documentation. Then I thought: would it be possible to transcribe the documentation of the symbols in the C header file into the generated Java code? Since C and Java have the same (mostly, anyways) comment syntax, this could even be done in a super naïve way by copying the literal strings. You would look at comment tokens that precede the target symbol (ignoring some whitespace perhaps) and copy it over. Looking at the Clang API, it seems they already associate documentation comments that belong to a declaration with said declaration. Clang attaches a `RawComment` to a `Decl` when the comment is immediately before it and separated only by whitespace. This could be used to transcribe the comment. Of course, the C documentation string wouldn't be in JavaDoc format, but even if it's in Doxygen or any other format, it's _much_ better than nothing at all. Is this something that you guys would be interested to look into? If I find the time I could give it a shot, but given my inexperience with Clang I'm not sure it would result in the best code :). Kind regards, Frederik van der Els PS: I saw the recent discussion on "jextract cannot generate portable code (anymore)" and it's about the exact same issue I reported in March last year ("Bindings crash on Windows where they would not before"). It's indeed the case that the mismatch is now made explicit by crashing, but in my case the C library didn't use any platform dependent types, so the type wouldn't have been used anyways. I would love to see a solution for this.

2 1

Bindings for Python
by Nir Lisker 12 Jan '26

12 Jan '26

Hi, Has interfacing with Python been looked at in the same sense that interfacing with Rust can be done with cbindgen? Has it been attempted internally and are there any writings on this? Thanks, Nir

2 2