December 2024 - jextract-dev

RFR: 7903922: Update copyright year for jextract in files where it was missed
by Nizar Benalla 20 Jan '25

20 Jan '25

I have sampled a few files to manually check that this works as intended, I got the list of files changed in a certain year by running. git log --since="Jan 1" --name-only --pretty=format: | sort -u > 2024file.list git log --oneline --since="1/1/2023" --until="31/12/2023" --name-only --pretty=format: | sort -u > 2023file.list And then used a script to update the copyright year, I did a random sampling of files to check that it worked as intended. A few files had their original copyright year changed because I noticed they were added in 2024 instead. ------------- Commit messages: - Manually fix files that were created on 11/01/24 - Update (C) for 2024 - Update (C) for 2023 Changes: https://git.openjdk.org/jextract/pull/267/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=267&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903922 Stats: 66 lines in 66 files changed: 0 ins; 0 del; 66 mod Patch: https://git.openjdk.org/jextract/pull/267.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/267/head:pull/267 PR: https://git.openjdk.org/jextract/pull/267

4 21

RFR: 7903923: Derive C_* layouts directly from the Linker
by Nizar Benalla 15 Jan '25

15 Jan '25

Depending on the platform, different `C_*` correspond to different `JAVA_*` types. We can get those values directly from the linker. This patch can allows us to have a common class for different platforms. Please review, and thanks in advance! ------------- Commit messages: - derive "C" types directly from the linker Changes: https://git.openjdk.org/jextract/pull/269/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=269&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903923 Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jextract/pull/269.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/269/head:pull/269 PR: https://git.openjdk.org/jextract/pull/269

4 17

RFR: Update gradle to version 8.11.1 and fix GitHub actions
by Jorn Vernee 10 Jan '25

10 Jan '25

Currently the github actions are failing because we depend on versions of the JDK (17 and 22), that are no longer available through the oracle/setup-java github action. There are 2 barriers to upgrading these JDK version to ones that are supported: 1. The current version of Gradle we are using doesn't run on newer Java versions 2. Due to our use of `--enable-preview` and `--release 22` to compile, we are locked to JDK 22. This PR updates Gradle to the latest version, which supports running on Java 23. It also drops the `--enable-preview` flag from compilation, which is not actually needed, allowing us to compile using JDK 23 as well. Both these changes then allow us to use JDK 23 to run Gradle, and as a toolchain JDK, in the GitHub actions. Since JDK 23 is available through oracle/setup-java, GitHub actions will work again. ------------- Commit messages: - remove --enable-preview in make build as well - add explicit javac exe suffix - Merge branch 'Stash' into UpdateGradle - work around deprecation - drop --enable-preview flags - Update GHA java versions to 23 - Update gradle to version 8.11.1 Changes: https://git.openjdk.org/jextract/pull/264/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=264&range=00 Stats: 14 lines in 4 files changed: 3 ins; 3 del; 8 mod Patch: https://git.openjdk.org/jextract/pull/264.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/264/head:pull/264 PR: https://git.openjdk.org/jextract/pull/264

3 14

RFR: 7903735: Remove redundant method in generated code
by Nizar Benalla 06 Jan '25

06 Jan '25

Was looking at older issues and saw an opportunity for a refractor. I don't see a dependent PR feature for this repo but this is meant to be merged after https://github.com/openjdk/jextract/pull/265 ------------- Commit messages: - use newer method from JDK 23 Changes: https://git.openjdk.org/jextract/pull/266/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=266&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903735 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jextract/pull/266.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/266/head:pull/266 PR: https://git.openjdk.org/jextract/pull/266

5 8

RFR: 7903917: Changes needed for jdk23-based makefile build
by Nizar Benalla 06 Jan '25

06 Jan '25

Changes necessary to bump the supported version to JDK 23. Passes tier 1. ------------- Commit messages: - CODETOOLS-7903917 Changes: https://git.openjdk.org/jextract/pull/265/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=265&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903917 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jextract/pull/265.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/265/head:pull/265 PR: https://git.openjdk.org/jextract/pull/265

3 8

Re: RFR: 7903731: Jextract should support macOS frameworks
by Marcono1234 06 Jan '25

06 Jan '25

On Fri, 27 Dec 2024 17:38:32 GMT, Nizar Benalla <nbenalla(a)openjdk.org> wrote: > 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` The review comments below are only suggestions, feel free to ignore them, I am not a JDK member. Though hopefully the comments are useful nonetheless. doc/GUIDE.md line 995: > 993: | Option | Meaning | > 994: |:-----------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| > 995: | `--mac-framework-dir <dir>` | specify the framework directory dir include files defaults to the current Mac OS X SDK dir This removes the need of having a compile_flags.txt with the required `-framework XYZ` options in the folder where jextract is ran | Is this "directory dir" intentional? Suggestion: | `--mac-framework-dir <dir>` | specify the framework directory include files defaults to the current Mac OS X SDK dir This removes the need of having a compile_flags.txt with the required `-framework XYZ` options in the folder where jextract is ran | doc/GUIDE.md line 996: > 994: |:-----------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| > 995: | `--mac-framework-dir <dir>` | specify the framework directory dir include files defaults to the current Mac OS X SDK dir This removes the need of having a compile_flags.txt with the required `-framework XYZ` options in the folder where jextract is ran | > 996: | `-f, framework <framekwork>` | specify the name of the library, path will be expanded to that of the framework folder | Typo? Suggestion: | `-f, framework <framework>` | specify the name of the library, path will be expanded to that of the framework folder | src/main/java/org/openjdk/jextract/JextractTool.java line 295: > 293: static boolean checkIfSupported( String option) { > 294: return platformOptions.contains(option); > 295: } Maybe this name `checkIfSupported` (and the way the method is used below) is a bit misleading, the method just seems to return if this is a known platform option, so what about `isPlatformOption` instead? src/main/java/org/openjdk/jextract/JextractTool.java line 387: > 385: parser.accepts("--version", "help.version", false); > 386: > 387: if(isMacOSX) { Suggestion: if (isMacOSX) { src/main/java/org/openjdk/jextract/JextractTool.java line 566: > 564: builder.addLibrary(library); > 565: } else { > 566: // not an absolute path, but--use-system-load-library was specified Suggestion: // not an absolute path, but --use-system-load-library was specified src/main/java/org/openjdk/jextract/JextractTool.java line 627: > 625: } > 626: > 627: private String parseFrameworkPath(String optionString) { Maybe rename to `format...` since this is not parsing anything? Suggestion: private String formatFrameworkPath(String optionString) { src/main/java/org/openjdk/jextract/impl/Utils.java line 50: > 48: import java.util.function.Consumer; > 49: import java.util.regex.Matcher; > 50: import java.util.regex.Pattern; Unused imports? src/main/resources/org/openjdk/jextract/impl/resources/Messages.properties line 93: > 91: Platform dependent options for running jextract \n\ > 92: --mac-framework-dir <dir> specify the framework directory \n\ > 93: -f <framekwork> specify framework library. -f libGL is equivalent to \n\ Suggestion: -f <framework> specify framework library. -f libGL is equivalent to \n\ ------------- PR Review: https://git.openjdk.org/jextract/pull/268#pullrequestreview-2526080122 PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1899854132 PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1899854182 PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1899854643 PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1899854842 PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1899855479 PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1899855778 PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1899855895 PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1899856061

3 2

Re: RFR: 7903731: Jextract should support macOS frameworks [v2]
by Nizar Benalla 02 Jan '25

02 Jan '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: Fix typos, rename some methods and bump copyright year to 2025 ------------- Changes: - all: https://git.openjdk.org/jextract/pull/268/files - new: https://git.openjdk.org/jextract/pull/268/files/efc469f0..aad02674 Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=01 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=00-01 Stats: 13 lines in 4 files changed: 1 ins; 2 del; 10 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

RFR: Touch up gradle build
by Jorn Vernee 13 Dec '24

13 Dec '24

I'm setting up the jextract repo on a new machine, and ran into a couple of small build issues that this PR addresses: 1.) intellij will try to collect all tasks defined by the gradle build, but this is currently failing if you don't have the jacoco agent configured, since that's needed to 'configure' one of the test tasks. The fix I added is to only lazily register the test task for coverage instead. 2.) If you want to debug a jtreg test through Intellij, it's nice to be able to build the test image and native test libraries as a pre-run step. I've added a new task called `testDeps` which does both of these things, and can be easily referenced from a run configuration. ------------- Commit messages: - Touch up build file Changes: https://git.openjdk.org/jextract/pull/263/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=263&range=00 Stats: 19 lines in 1 file changed: 9 ins; 5 del; 5 mod Patch: https://git.openjdk.org/jextract/pull/263.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/263/head:pull/263 PR: https://git.openjdk.org/jextract/pull/263

2 3

RFR: 7903878: jextract should derive struct field offsets from struct layouts
by Nizar Benalla 11 Dec '24

11 Dec '24

Please read the JBS issue for more details. Currently jextract emits hardwired offsets, it would be better if the offsets could be computed dynamically from the struct layouts. Passes all tests, unsure if this patch requires new tests. Note: I used `fieldElementPaths(field.name())))` instead of the `javaName` to deal with nested structs. It seems like GitHub actions are broken for Ubuntu? will look into this next week if necessary. ------------- Commit messages: - jextract should derive struct field offsets from struct layouts Changes: https://git.openjdk.org/jextract/pull/262/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=262&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903878 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jextract/pull/262.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/262/head:pull/262 PR: https://git.openjdk.org/jextract/pull/262

3 4

Error with const variables
by Adrian Trapletti 09 Dec '24

09 Dec '24

Hi, I run jextract on https://github.com/ERGO-Code/HiGHS/blob/master/src/interfaces/highs_c_api.h . If I use the Java bindings to access the const variables I get "java.lang.UnsatisfiedLinkError: unresolved symbol". For example ... long sense = kHighsObjSenseMinimize(); ... results in java.lang.UnsatisfiedLinkError: unresolved symbol: kHighsObjSenseMinimize at com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h.lambda$findOrThrow$0(highs_c_api_h.java:44) at java.base/java.util.Optional.orElseThrow(Optional.java:403) at com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h.findOrThrow(highs_c_api_h.java:44) at com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h$kHighsObjSenseMinimize$constants.<clinit>(highs_c_api_h.java:804) at com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h.kHighsObjSenseMinimize(highs_c_api_h.java:834) at com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.BindingsTest.solveLinearProgramReturnsExpectedSolution(BindingsTest.java:32) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at java.base/java.util.ArrayList.forEach(ArrayList.java:1597) at java.base/java.util.ArrayList.forEach(ArrayList.java:1597) (https://github.com/atraplet/highs4j and run the unit tests) What do I miss here? Thx and best regards, 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.

2 3