May 2024 - jextract-dev

RFR: Typo in word directory
by Brayan Munoz V. 12 Jun '24

12 Jun '24

This commit just fix a typo in the word directory. Please add the following to the description of the pull request: 1. A brief recap of the status quo, as it relates to the subject of the pull request. 2. A description of why the status quo is problematic. 3. A description of how this pull request addresses this issue. 4. If you ran into issues while making changes in the code that you had to work around, please mention these as well, as this helps reviewers understand the changes that have been made. For 1 and 2 it is also okay to refer to the JBS ticket, if that already contains a comprehensive problem description. Please test your pull request before submitting it by running `./gradlew jtreg`. If you're not able to test locally on your machine, please indicate this in the pull request description, and indicate which testing has been done instead (or indicate that no testing has been done). It is possible to run tests through Github actions if you enable them for your fork (this is free). Github actions can be enabled for your fork from the 'Actions' tab. The tests will then run automatically after the pull request has been created. ------------- Commit messages: - Typo in word directory Changes: https://git.openjdk.org/jextract/pull/240/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=240&range=00 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jextract/pull/240.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/240/head:pull/240 PR: https://git.openjdk.org/jextract/pull/240

2 2

RFR: Reference latest JEP of FFM API.
by Brayan Munoz V. 12 Jun '24

12 Jun '24

Let's reference the JEP 454 which is the latest for FFM API instead of the JEP 442 of the third preview. In the README.md the 454 is already being referenced. https://github.com/openjdk/jextract/blob/b4da3284d41863af47d4a36b5829849b27… Please add the following to the description of the pull request: 1. A brief recap of the status quo, as it relates to the subject of the pull request. 2. A description of why the status quo is problematic. 3. A description of how this pull request addresses this issue. 4. If you ran into issues while making changes in the code that you had to work around, please mention these as well, as this helps reviewers understand the changes that have been made. For 1 and 2 it is also okay to refer to the JBS ticket, if that already contains a comprehensive problem description. Please test your pull request before submitting it by running `./gradlew jtreg`. If you're not able to test locally on your machine, please indicate this in the pull request description, and indicate which testing has been done instead (or indicate that no testing has been done). It is possible to run tests through Github actions if you enable them for your fork (this is free). Github actions can be enabled for your fork from the 'Actions' tab. The tests will then run automatically after the pull request has been created. ------------- Commit messages: - Reference latest JEP of FFM API. Changes: https://git.openjdk.org/jextract/pull/243/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=243&range=00 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jextract/pull/243.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/243/head:pull/243 PR: https://git.openjdk.org/jextract/pull/243

3 4

RFR: 7903727: Remove the reliance on String Templates feature
by Nizar Benalla 05 Jun '24

05 Jun '24

This PR aims to replace the usage of string templates with `String::format`, since there will be no string template feature in JDK 23. I tried to keep similar indentation and convert them in-place, to make reviewing the changes easier. ------------- Commit messages: - convert string template usage to String::format Changes: https://git.openjdk.org/jextract/pull/244/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=244&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903727 Stats: 370 lines in 9 files changed: 62 ins; 4 del; 304 mod Patch: https://git.openjdk.org/jextract/pull/244.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/244/head:pull/244 PR: https://git.openjdk.org/jextract/pull/244

3 46

Errors on build
by Nir Lisker 31 May '24

31 May '24

Hi, In Utils::methodTypeFor(Type.Function type), line 275, I get a compilation error: no suitable method found for methodType(Class <CAP#1>,List<Class<CAP#2>>) MethodType.methodType(carrierFor(type.returnType()), type.argumentTypes().stream().map(Utils::carrierFor).toList()); ^ method MethodType.methodType(Class<?>,Class<?>[]) is not applicable (argument mismatch; List<Class<CAP#3>> cannot be converted to Class<?>[]) method MethodType.methodType(Class<?>,List<Class<?>>) is not applicable (argument mismatch; List<Class<CAP#3>> cannot be converted to List<Class<?>>) method MethodType.methodType(Class<?>,Class<?>,Class<?>...) is not applicable (argument mismatch; List<Class<CAP#3>> cannot be converted to Class<?>) method MethodType.methodType(Class<?>,Class<?>) is not applicable (argument mismatch; List<Class<CAP#3>> cannot be converted to Class<?>) method MethodType.methodType(Class<?>,MethodType) is not applicable (argument mismatch; List<Class<CAP#3>> cannot be converted to MethodType) where CAP#1,CAP#2,CAP#3 are fresh type-variables: CAP#1 extends Object from capture of ? CAP#2 extends Object from capture of ? CAP#3 extends Object from capture of ? There is a problem with type inference. Eclipse's ECJ also has this problem. Another one is in HeaderFileBuilder line 326: Cannot infer type argument(s) for <R> map(Function<? super T,? extends R>). I'm using the master branch commit ID d87ddec91bd5aceaa3882f3bd6d75b18d77e9842 in case this is the wrong branch. Maybe I have some local configuration problem. - Nir

2 1

RFR: Update macOS version of the OpenGL sample to match the current state of OpenGL/Glut on Mac
by Ana Maria Mihalceanu 31 May '24

31 May '24

Running the macOS instructions for the [OpenGL sample ](https://github.com/openjdk/jextract/tree/master/samples/opengl) results in failure as Apple discontinued official support for OpenGL (core) and the native `libGL.dylib` doesn't exist anymore. Below is the situation in details: * running [compile.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/… or [compilesource.sh](https://github.com/openjdk/jextract/blob/master/samples/o… will produce Java code that compiles. * attempting to run [run.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/run.… will result in error Exception in thread "main" java.lang.ExceptionInInitializerError at Teapot.main(Teapot.java:75) Caused by: java.lang.IllegalArgumentException: Cannot open library: libGL.dylib at java.base/java.lang.foreign.SymbolLookup.libraryLookup(SymbolLookup.java:314) at java.base/java.lang.foreign.SymbolLookup.libraryLookup(SymbolLookup.java:266) at opengl.glut_h_3.<clinit>(glut_h_3.java:58) ... 1 more But OpenGL and Glut frameworks are still pre-installed with Apple development tools. This PR fixes the above error by referencing to the OpenGL and Glut frameworks available with Xcode: * `jextract` finds the header files via [compile_flags.txt]([[compile.sh](https://github.com/openjdk/jextract/blob/m… * At runtime, the generated header class finds the shared libraries thanks to providing `-l :/System/Library/Frameworks/GLUT.framework/Versions/Current/GLUT` and `-l -l :/System/Library/Frameworks/OpenGL.framework/Versions/Current/OpenGL` to `jextract` command. * A small side effect: the `Teapot.java` class is updated to use generated `glutDisplayFunc$func` and `glutIdleFunc$func`classes. Generated code varies depending on OpenGL/Glut distribution used. - [x] Tested locally on macOS Sonoma 14.4.1 with JDK 22 and using [jextract binaries](https://jdk.java.net/jextract/). - [ ] The code from `Teapot.java` is common for all the operating systems. Additional tests should be done on Windows/Linux. **Reviewers** [Athijegannathan Sundararajan](https://openjdk.org/census#sundar) (@sundararajana - Committer) ------------- Commit messages: - Update MacOs version of the sample to match the current state of OpenGL. Changes: https://git.openjdk.org/jextract/pull/245/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=245&range=00 Stats: 10 lines in 4 files changed: 0 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jextract/pull/245.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/245/head:pull/245 PR: https://git.openjdk.org/jextract/pull/245

3 10

MacOS
by Michael Hall 30 May '24

30 May '24

I noticed a pointer to jextract doc in the Java Newsletter that began with a typical way to run showing a normal command invocation. jextract \ … On MacOS jextract --help zsh: command not found: jextract (base) mjh@MacBook-Pro-2 weka % /usr/libexec/java_home --exec jextract WARNING: Using incubator modules: jdk.incubator.foreign, jdk.incubator.jextract Expected a header file (base) mjh@MacBook-Pro-2 weka % /usr/libexec/java_home --exec jextract --help WARNING: Using incubator modules: jdk.incubator.jextract, jdk.incubator.foreign Non-option arguments: [String] -- header file Option Description ------ ----------- -?, -h, --help print help ... The command is default not there on MacOS (M3 Sonoma 14.5) I think this has been discussed before and java has no way to provide these default invocations for new commands on MacOS? Is that still correct with no way planned to ever include new commands? Also I might be mistaken but I thought FFM and related were out of incubator at 22? I thought possibly /usr/libexec/java_home was in this case for some reason not defaulting to the latest installed jdk (openjdk 22.0.1 2024-04-16) But /usr/libexec/java_home --version 22 --exec jextract —help Gets the same It also seems jextract has no option to indicate the current installed version?

2 1

new jextract builds
by Maurizio Cimadamore 30 May '24

30 May '24

Hi, we have refreshed the jextract binary builds with some small updates: * put the jextract launcher into a "bin" folder in the jextract root folder [1] * reduce the size of the Linux downloadable, by removing duplicate versions of libclang [2] * tweak the build to make the jextract launcher executable [also in 1] * tweak the build to bundle an OpenJDK runtime [3] You can find the binaries in the usual place: https://jdk.java.net/jextract/ Cheers Maurizio [1] - https://github.com/openjdk/jextract/pull/247 [2] - https://github.com/openjdk/jextract/pull/246 [3] - https://mail.openjdk.org/pipermail/jextract-dev/2024-May/001709.html

2 1

RFR: Add support for bin folder in makefile
by Maurizio Cimadamore 28 May '24

28 May '24

A previous PR changed the gradle build to emit launcher scripts in a separate "bin" folder. However, that PR did not make any changes to the makefiles used to produce the binary bundles. This PR rectifies that. Tested locally. ------------- Commit messages: - Initial push Changes: https://git.openjdk.org/jextract/pull/247/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=247&range=00 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jextract/pull/247.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/247/head:pull/247 PR: https://git.openjdk.org/jextract/pull/247

2 4

RFR: Remove duplicate copies of libclang on Linux
by Maurizio Cimadamore 28 May '24

28 May '24

On Linux, libclang.so is found in three forms: * `libclang.so.13.0.0`, this is the real library * `libclang.so.13`, this is a symlink that points to the above library * `libclang.so`, this is a symlink that points to the above symlink Because of this, and because Gradle lacks ability to distinguish between real filenames and symlinks, we end up (on Linux) with multiple versions of libclang, which significantly impact on the size of the final jextract artifact. The solution is to add some special logic on Linux where: * only `libclang.so.13.0.0` is copied from LLVM * `libclang.so.13.0.0` is later renamed to `libclang.so` This PR implement such changes both for gradle and make build (both have been tested locally). ------------- Commit messages: - Add makefile changes - Initial push Changes: https://git.openjdk.org/jextract/pull/246/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=246&range=00 Stats: 17 lines in 3 files changed: 15 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jextract/pull/246.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/246/head:pull/246 PR: https://git.openjdk.org/jextract/pull/246

2 6

RFR: 7903723: Jextract binary should live in a bin folder
by Maurizio Cimadamore 21 May '24

21 May '24

This PR reintroduces the `bin` folder for jextract launcher scripts. ------------- Commit messages: - Initial push Changes: https://git.openjdk.org/jextract/pull/242/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=242&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903723 Stats: 11 lines in 3 files changed: 3 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jextract/pull/242.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/242/head:pull/242 PR: https://git.openjdk.org/jextract/pull/242

2 2