March 2025 - jextract-dev

RFR: 7903933: Move sharable items from different generations to a common file
by Nizar Benalla 08 May '25

08 May '25

Please review this patch to move the `C_*` layouts and the static utility methods into separate classes: `LayoutUtils.java` and `FFMUtils.java`, respectively. - The names could later be personalized through a JSON configuration. - We can use static imports if the `-t` option is no used and the files are generated into the default package, in that case we use the classname to call the static methods or use the `C_*` constants. Some tests had to be modified slightly, either by adding new static imports or replacing classnames. ------------- Commit messages: - move sharable items to a common class Changes: https://git.openjdk.org/jextract/pull/278/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=278&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903933 Stats: 411 lines in 21 files changed: 233 ins; 106 del; 72 mod Patch: https://git.openjdk.org/jextract/pull/278.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/278/head:pull/278 PR: https://git.openjdk.org/jextract/pull/278

4 35

RFR: 7903984: Inline upcallHandle method to reduce shared code across multiple generations
by Nizar Benalla 11 Apr '25

11 Apr '25

Please review this patch to inline the upcallHandle method, reducing the amount of shared items across multiple jextract generations. TIA ------------- Commit messages: - remove whitespace - inline method Changes: https://git.openjdk.org/jextract/pull/279/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=279&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903984 Stats: 18 lines in 2 files changed: 8 ins; 8 del; 2 mod Patch: https://git.openjdk.org/jextract/pull/279.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/279/head:pull/279 PR: https://git.openjdk.org/jextract/pull/279

3 8

RFR: 7903983: Remove redundant findOrThrow method
by Nizar Benalla 03 Apr '25

03 Apr '25

`SymbolLookup::FindOrThrow` was introduced in JDK 23, making this method in the generated code redundant: static MemorySegment findOrThrow(String symbol) { return SYMBOL_LOOKUP.findOrThrow(symbol); } The generated method should have been dropped in https://github.com/openjdk/jextract/commit/a53f5c05e3ee2cca057cadb78b2e381c… but I didn't cleanup all uses of it. A small additional cleanup in PR is that the newly added option for framworks now uses `--` rather than `-` TIA ------------- Commit messages: - remove rendundant method - longer cmd option should use -- rather than - Changes: https://git.openjdk.org/jextract/pull/280/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=280&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903983 Stats: 27 lines in 5 files changed: 3 ins; 4 del; 20 mod Patch: https://git.openjdk.org/jextract/pull/280.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/280/head:pull/280 PR: https://git.openjdk.org/jextract/pull/280

3 3

Bindings crash on Windows where they would not before
by jextract＠xpple.dev 31 Mar '25

31 Mar '25

Hello, Firstly, thanks to the people behind this tool, I really like it. I have used it for both C and Rust libraries with great success. Unfortunately though, it seems commit [1] from PR [2] and relevant issue [3] caused bindings to generate that crash on Windows, where they before would not. I let GitHub Actions generate my bindings on an Ubuntu runner, where the size of the type `long` is `64` bits. On Windows however, the size of this type is `32` bits (thank Microsoft for that...). This means that on Windows, the bindings crash with the message `java.lang.ClassCastException: class jdk.internal.foreign.layout.ValueLayouts$OfIntImpl cannot be cast to class java.lang.foreign.ValueLayout$OfLong (jdk.internal.foreign.layout.ValueLayouts$OfIntImpl and java.lang.foreign.ValueLayout$OfLong are in module java.base of loader 'bootstrap')`. Before the `long` type was of _fixed_ size (regardless of the actual size), preventing a mismatch. While I know platform agnosticy is not a specific goal of jextract, this seems easy enough to provide a fix for. For instance the platform check could be done at runtime. In the meantime, what would your recommended fix be for my issue? Kind regards, Frederik van der Els [1] https://github.com/openjdk/jextract/commit/1c614f31fac9e6309e8d3498a128ac94… [2] https://github.com/openjdk/jextract/pull/269 [3] https://bugs.openjdk.org/browse/CODETOOLS-7903923

3 3

ffmbindings manual bindings to C++
by Lain Lain 26 Mar '25

26 Mar '25

3 8

RFR: 7903928: update build.gradle to use JDK 23
by Athijegannathan Sundararajan 19 Mar '25

19 Mar '25

We've updated native makefile to use JDK 23 ( https://github.com/openjdk/jextract/commit/0b89a462146940a2ec90e34eeb5df3d4… ) While build.gradle works & expects jdk 23, it still refers to JDK var as "jdk22_home" and passes --release to be 22. Also jextract version is "22". ------------- Commit messages: - 7903928: update build.gradle to use JDK 23 Changes: https://git.openjdk.org/jextract/pull/271/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=271&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903928 Stats: 8 lines in 1 file changed: 1 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jextract/pull/271.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/271/head:pull/271 PR: https://git.openjdk.org/jextract/pull/271

7 10

RFR: Gradle 8.11.1 update cleanups
by Jorn Vernee 13 Mar '25

13 Mar '25

Some things were missed as part of: https://github.com/openjdk/jextract/pull/264 - The action to validate the gradle wrapper accidentally uses a deprecated version - The readme was not updated. ------------- Commit messages: - update readme - use non-deprecated action to validate gradle wrapper Changes: https://git.openjdk.org/jextract/pull/272/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=272&range=00 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jextract/pull/272.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/272/head:pull/272 PR: https://git.openjdk.org/jextract/pull/272

3 4

Re: RFR: 7903731: Jextract should support macOS frameworks [v13]
by Nizar Benalla 10 Mar '25

10 Mar '25

> Read the JBS issue for more detail. > > This patch adds two new mac specific options, to make it easier to use frameworks and remove the need of a `compile_flags.txt` file. An exception is thrown if those options are used from an other platform, the error message is inspired from `jpackage` Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: review feedback: -F and -framework options should be recognized on non-mac platforms ------------- Changes: - all: https://git.openjdk.org/jextract/pull/268/files - new: https://git.openjdk.org/jextract/pull/268/files/e4c2e55a..7e628e81 Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=12 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=11-12 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jextract/pull/268.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/268/head:pull/268 PR: https://git.openjdk.org/jextract/pull/268

3 3

Re: RFR: 7903731: Jextract should support macOS frameworks [v12]
by Nizar Benalla 10 Mar '25

10 Mar '25

> Read the JBS issue for more detail. > > This patch adds two new mac specific options, to make it easier to use frameworks and remove the need of a `compile_flags.txt` file. An exception is thrown if those options are used from an other platform, the error message is inspired from `jpackage` Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: review feedback: improve error message ------------- Changes: - all: https://git.openjdk.org/jextract/pull/268/files - new: https://git.openjdk.org/jextract/pull/268/files/09dfa8c3..e4c2e55a Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=11 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jextract/pull/268.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/268/head:pull/268 PR: https://git.openjdk.org/jextract/pull/268

3 6

Re: RFR: 7903731: Jextract should support macOS frameworks [v11]
by Nizar Benalla 07 Mar '25

07 Mar '25

> Read the JBS issue for more detail. > > This patch adds two new mac specific options, to make it easier to use frameworks and remove the need of a `compile_flags.txt` file. An exception is thrown if those options are used from an other platform, the error message is inspired from `jpackage` Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: improve error message ------------- Changes: - all: https://git.openjdk.org/jextract/pull/268/files - new: https://git.openjdk.org/jextract/pull/268/files/da22de95..09dfa8c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=10 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=09-10 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jextract/pull/268.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/268/head:pull/268 PR: https://git.openjdk.org/jextract/pull/268

2 2