February 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

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

jextract fails to work on sd-daemon.h due to wrong handling of __INCLUDE_LEVEL__
by Nils Kattenbeck 17 Feb '25

17 Feb '25

Dear all, Today I tried to use jextract on sd-daemon.h (from systemd) to access the sd_notify* class of functions. To my surprise this did not work and returned in the following error message: ../jextract-21/bin/jextract --source -t foo.bar /usr/include/systemd/sd-daemon.h WARNING: A restricted method in java.lang.foreign.AddressLayout has been called WARNING: java.lang.foreign.AddressLayout::withTargetLayout has been called by module org.openjdk.jextract WARNING: Use --enable-native-access=org.openjdk.jextract to avoid a warning for this module /usr/include/systemd/_sd-common.h:23:4: error: "Do not include _sd-common.h directly; it is a private header." which comes down to the following preprocessor code in _sd-common.h (which is included by sd-daemon.h): #if defined(__INCLUDE_LEVEL__) && __INCLUDE_LEVEL__ <= 1 && !defined(__COVERITY__) # error "Do not include _sd-common.h directly; it is a private header." #endif It seems like jextract does not increase the __INCLUDE_LEVEL__ resulting in this error. However, it does seem to define it which makes this more curious. The fix would be to either a) not set it at all or b) correctly increment it when parsing files from an #include statement. For now I have been able to circumvent this by telling jextract to also define __COVERITY__ though this is only a very dirty hack and will not work in every instance. Cheers, Nils

3 7

Re: RFR: 7903731: Jextract should support macOS frameworks [v3]
by Nizar Benalla 03 Feb '25

03 Feb '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: use consistent spacing ------------- Changes: - all: https://git.openjdk.org/jextract/pull/268/files - new: https://git.openjdk.org/jextract/pull/268/files/aad02674..9ce83f36 Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=02 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=01-02 Stats: 2 lines in 1 file changed: 0 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

4 11