September 2025 - jextract-dev

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

RFR: 7904073: Derive required symbols from client code to minimize generated bindings
by Nizar Benalla 16 Oct '25

16 Oct '25

Please review this change to add a small sample that extracts full bindings once, scans the compiled client classes to collect actually referenced symbols, filters the includes list, and re-runs jextract to produce a slim binding set. ------------- Commit messages: - add new sample Changes: https://git.openjdk.org/jextract/pull/288/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=288&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904073 Stats: 183 lines in 7 files changed: 182 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jextract/pull/288.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/288/head:pull/288 PR: https://git.openjdk.org/jextract/pull/288

3 7

RFR: 7904085: Changes needed for jdk25-based makefile build
by Nizar Benalla 25 Sep '25

25 Sep '25

A simple version change, since JDK 25 was released. ------------- Commit messages: - 8368566 changes Changes: https://git.openjdk.org/jextract/pull/291/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=291&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904085 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jextract/pull/291.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/291/head:pull/291 PR: https://git.openjdk.org/jextract/pull/291

3 4

RFR: 7904079: Fix setting up length parameter for CXUnsavedFiles Struct
by Varada M 24 Sep '25

24 Sep '25

CXUnsavedFile struct contains three members, first two are pointers and last one is unsigned long. When jextract makes downcall to clang_reparseTranslationUnit_Impl it sets up the third parameter in the struct incorrectly. It sets INT instead of LONG so on big endian platform the parameter will be set differently. JBS Issue : [CODETOOLS-7904079](https://bugs.openjdk.org/browse/CODETOOLS-7904079) ------------- Commit messages: - CODETOOLS-7904079: Fix setting up length parameter for CXUnsavedFiles Struct Changes: https://git.openjdk.org/jextract/pull/289/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=289&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7904079 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jextract/pull/289.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/289/head:pull/289 PR: https://git.openjdk.org/jextract/pull/289

5 21

RFR: Fix GitHub actions
by Jorn Vernee 19 Sep '25

19 Sep '25

Currently we use JDK 23 as both the JDK on which to run Gradle (sourced from oracle.com) and the JDK with which to build jextract (sourced from jdk.java.net) However, neither of these sources support JDK 23 any more. This PR proposes to change the build JDK to 25. Since the version of Gradle that we use doesn't support 25, we use 21 for running Gradle. JDK 21 is sourced from oracle.com (it is LTS there), and 25 is sourced from jdk.java.net. i.e. the source of either is not changed. Finally, the current actions are configured to use ubuntu-20.04, since we have a binary available for that system from the llvm-project releases page on github. However, runners with that version of ubuntu seem to be in short supply, and a job I tried to run took more than 24 hours to be picked (I ended up just cancelling it). I've switched the script to use ubuntu-latest, which seems to work fine with the same binary, and is much more readily available as a runner. See here a successful run: https://github.com/JornVernee/jextract/actions/runs/17861448305 ------------- Commit messages: - Try running on ubuntu-latest - Change Java versions Changes: https://git.openjdk.org/jextract/pull/290/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=290&range=00 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jextract/pull/290.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/290/head:pull/290 PR: https://git.openjdk.org/jextract/pull/290

2 2

Function pointers and GraalVM
by Manuel Bleichenbacher 10 Sep '25

10 Sep '25

Hi jextract team I've been playing with the upcoming GraalVM 25 and its support for FFM. But I've run into an issue with code generated by jextract related to function pointers: it always instantiates both the downcall and upcall method handles, independent of which one is actually used. In my case, I would only need the downcall handle. The unnecessary upcall handle depends on another method ("apply") that GraalVM has correctly identified to never be called and is thus omitted from the native image. As a result, the application crashes at run-time. It wouldn't be such a problem if I was dealing with one or two function pointers. Then I would manually create the required FFM code with downcall handles only. However, I'm dealing with COM interfaces and the macOS IOKit version thereof: *typedef* *struct* IOUSBInterfaceStruct942 { IUNKNOWN_C_GUTS; IOReturn (*CreateInterfaceAsyncEventSource)(*void* **self*, CFRunLoopSourceRef *source); CFRunLoopSourceRef (*GetInterfaceAsyncEventSource)(*void* **self*); IOReturn (*CreateInterfaceAsyncPort)(*void* **self*, mach_port_t *port); mach_port_t (*GetInterfaceAsyncPort)(*void* **self*); IOReturn (*USBInterfaceOpen)(*void* **self*); IOReturn (*USBInterfaceClose)(*void* **self*); IOReturn (*GetInterfaceClass)(*void* **self*, UInt8 *intfClass); IOReturn (*GetInterfaceSubClass)(*void* **self*, UInt8 *intfSubClass); IOReturn (*GetInterfaceProtocol)(*void* **self*, UInt8 *intfProtocol); IOReturn (*GetDeviceVendor)(*void* **self*, UInt16 *devVendor); ... These are structs that almost exclusively consist of function pointers. In the case of IOKit, the two main ones consist of 40 and 50 function pointers. Am I correct that there is currently no way to suppress the generation of upcall method handles? Are there any plans to to make the jextract generated code work well with GraalVM? Regards Manuel

2 4