November 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

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

RFR: Add `--library-path-resolver` option for custom library path resolving
by devjeonghwan 14 Nov '25

14 Nov '25

#### 1. Status Quo Currently, `jextract` generates code using two standard loading mechanisms: 1. **Default:** `SymbolLookup.libraryLookup(System.mapLibraryName("name"), ...)` 2. **With `--use-system-load-library`:** `System.loadLibrary("name")` Both methods depend on static paths (e.g., `java.library.path`) and do not support runtime path resolution (hooking) without manual code modification. #### 2. Problem Standard loading fails in dynamic deployment scenarios: * **Bundled Libraries:** Native libraries inside JARs (extracted to temp directories) require loading from an absolute path. * **Dynamic Paths:** Paths determined at runtime based on OS/Arch cannot be handled by static system properties. Users currently must manually edit the generated source to inject custom loading logic. #### 3. Fix Introduced a new CLI option: `--library-path-resolver`. This option injects a user-defined static method to resolve the library path (or name) at runtime. **Usage:** jextract ... --library-path-resolver com.example.Resolver#resolvePath **Code Generation:** **Case 1: Default (SymbolLookup)** // Before SymbolLookup.libraryLookup(System.mapLibraryName("foo"), ARENA); // After SymbolLookup.libraryLookup(com.example.Resolver.resolvePath("foo"), ARENA); **Case 2: With `--use-system-load-library`** // Before System.loadLibrary("foo"); // After System.load(com.example.Resolver.resolvePath("foo")); #### 4. Additional Notes * **Method Signature:** The resolver method must match `String <method_name>(String <parameter_name>)`. * **Return Value:** * For `--use-system-load-library`: Must return an **absolute path** (required by `System.load()`). * For Default: Returns a path or name accepted by `SymbolLookup`. #### 5. Testing Added `TestLibraryPathResolver`. * Dynamic compilation and loading of a custom resolver class. * Correct code generation when the option is present. * Verifying that the custom resolver is actually invoked and that the native library is successfully loaded and linked via the resolved path All tests pass locally. ------------- Commit messages: - Remove trailing whitespace in `TestLibraryPathResolver.java` - Refactor and rename library path resolver test - Add test for custom library path resolver functionality - Support custom library path resolvers in system library loading Changes: https://git.openjdk.org/jextract/pull/295/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=295&range=00 Stats: 193 lines in 10 files changed: 176 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jextract/pull/295.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/295/head:pull/295 PR: https://git.openjdk.org/jextract/pull/295

2 12

RFR: Fix incorrect base offset handling in generated array field accessors
by devjeonghwan 12 Nov '25

12 Nov '25

#### 1. Status Quo Array field accessors generated by jextract (e.g., for `int arr[3]`) currently use a fixed base offset `0L` in `VarHandle.get/set` or `MethodHandle.invokeExact`. This causes all array accesses to start from the beginning of the struct, ignoring the field’s actual offset. #### 2. Problem Because of the missing base offset, writing to array elements in nested structs or unions can overwrite unrelated fields in the same structure. For example, updating `maxBlockDimension[1]` could corrupt `computeCapabilityMajor` or other preceding fields. typedef struct CudaDeviceInfo_st { int id; int computeCapabilityMajor; int computeCapabilityMinor; int multiprocessorCount; int warpSize; int maxThreadsPerBlock; int maxThreadsPerMultiprocessor; int maxBlockDimension[3]; int maxGridDimension[3]; bool unifiedAddressing; bool integratedMemory; } CudaDeviceInfo; #### 3. Fix This patch updates `emitFieldArrayGetter` and `emitFieldArraySetter` to pass the correct field offset (`offsetField`) to all generated array accessors. This ensures correct addressing for both primitive and struct/union element arrays. **Example:** // Before varHandle.get(struct, 0L, index); // After varHandle.get(struct, fieldOffset, index); #### 4. Additional Notes While the more idiomatic FFM approach of generating 'path-based' `VarHandle`s (e.g., `LAYOUT.varHandle(groupElement(...), ...)`) was considered, this patch takes a minimal-change approach. So It retains the existing handle and fixes the bug by passing the `fieldOffset` as the base offset (replacing `0L`). If the path-based `VarHandle` approach is preferred, I can rework this. #### 5. Testing New test cases were added to verify correct offset handling for: * Primitive arrays in structs * Struct arrays in structs * Struct arrays inside unions All tests pass locally. ------------- Commit messages: - Update copyright year to 2025 - Simplify test method names for clarity - Fix nits - Add test for struct and union array field handling - Update parameter type `Variable` to `Declaration.Variable` in `emitFieldArrayGetter` and `emitFieldArraySetter` - Add `offsetField` parameter to emit method for `FieldArray` getter and setter Changes: https://git.openjdk.org/jextract/pull/294/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=294&range=00 Stats: 245 lines in 3 files changed: 235 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jextract/pull/294.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/294/head:pull/294 PR: https://git.openjdk.org/jextract/pull/294

4 12

RFR: Generate Java enums
by Vivek Narang 09 Nov '25

09 Nov '25

We are using jextract in our [cuVS Java](https://github.com/rapidsai/cuvs/tree/branch-25.08/java) project. As of now, jextract generates individual getter functions for the C enums. This results in code where it is difficult to disambiguate which getter functions are logically grouped together for a particular Enum. Additionally, given the lack of this capability, we also have to manually create and maintain Java enums for each enum in the C layer. In this PR, I wish to introduce an option to additionally generate Java enums by passing an optional flag `--generate-java-enums`. In case a Java user wishes to use bitwise operations on the enums, they can use the enum's `.ordinal()` method for this. The original static getter methods will still be generated as before. Example C enum: enum SIZE { S, M, L }; Produces the following with jextract: private static final int S = (int)0L; public static int S() { return S; } private static final int M = (int)1L; public static int M() { return M; } private static final int L = (int)2L; public static int L() { return L; } With this feature enabled using the `--generate-java-enums` flag, the following enum is generated (in addition to the above): public enum Size { S(0), M(1), L(2); private final int value; private Size(int value) {; this.value = value; } public int getValue() { return this.value; } } This PR is created against the `jdk22` branch. I will rebase it to `master` branch if needed. ------------- Commit messages: - Remove extra space in messages.properties - Generate enums in header file instead - Initial work Changes: https://git.openjdk.org/jextract/pull/284/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=284&range=00 Stats: 184 lines in 12 files changed: 168 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jextract/pull/284.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/284/head:pull/284 PR: https://git.openjdk.org/jextract/pull/284

4 12

RFR: 7903947: Access to function pointers in structs could be streamlined
by Nizar Benalla 04 Nov '25

04 Nov '25

Please review this patch to add a new option where you can generate an direct invoker methods. This feature is intended to be used on structs that are just a collection of functions we had like to call. If this feature is used, we remove the getter to avoid name collisions as we assume this is similar to an interface. Changes to `GUIDE.md` have been intentionally left out from this initial patch to make reviews easier. struct Foo { struct Bar (*a)(void); struct Bar (*b)(int); }; Before var foo = alloc_callback_h.foo(); var barA = Foo.a.invoke(Foo.a(foo), arena); var barB = Foo.b.invoke(Foo.b(foo), arena, 100); After var foo = alloc_callback_h.foo(); var barA = Foo.a(foo, arena); var barB = Foo.b(foo, arena, 100); ------------- Commit messages: - add functional dispatch feature Changes: https://git.openjdk.org/jextract/pull/287/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=287&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903947 Stats: 294 lines in 8 files changed: 263 ins; 6 del; 25 mod Patch: https://git.openjdk.org/jextract/pull/287.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/287/head:pull/287 PR: https://git.openjdk.org/jextract/pull/287

4 11