From jorn.vernee at oracle.com Thu May 2 16:53:57 2024 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Thu, 2 May 2024 18:53:57 +0200 Subject: New Jextract 22 builds are live! Message-ID: <164c8d08-24b2-4fc8-af44-9fd5510208c4@oracle.com> Hi all, We've just published a new build of jextract 22 over on: https://jdk.java.net/jextract/ Since the last version, notable changes that affect end-users are: 1. 7903720: Change layout of jextract image 2. 7903715: Jextract generates duplicate allocator parameters 3. 7903697: jextract doesn't use name in asm label attribute 4. 7903704: Expose addresses of native functions 5. Fix javadoc generation and add check to testing suite 6. 7903680: Dependency checker doesn't handle function pointers and nested types (see links in footer) With regards to (1): we've changed the layout of the jextract image. The new layout now has the 2 launcher scripts in the root directory, and a separate 'runtime' folder with the bundled jlink runtime used to run jextract. This change should make it possible to add the jextract launcher scripts to the PATH, without also adding the 'java' launcher from the runtime image. Just note that changes might be needed to scripts that were calling jextract, in order to account for the new layout. Additionally, we have recently published a guide for jextract at: https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md Jorn [1]: https://github.com/openjdk/jextract/pull/241 [2]: https://github.com/openjdk/jextract/pull/238 [3]: https://github.com/openjdk/jextract/pull/232 [4]: https://github.com/openjdk/jextract/pull/228 [5]: https://github.com/openjdk/jextract/pull/227 [6]: https://github.com/openjdk/jextract/pull/224 From duke at openjdk.org Fri May 3 19:13:29 2024 From: duke at openjdk.org (Brayan Munoz V.) Date: Fri, 3 May 2024 19:13:29 GMT Subject: RFR: Typo in word directory Message-ID: 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 From mcimadamore at openjdk.org Fri May 3 21:12:03 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 3 May 2024 21:12:03 GMT Subject: RFR: Typo in word directory In-Reply-To: References: Message-ID: On Mon, 29 Apr 2024 18:03:12 GMT, Brayan Munoz V. wrote: > 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. Marked as reviewed by mcimadamore (Reviewer). Thanks! ------------- PR Review: https://git.openjdk.org/jextract/pull/240#pullrequestreview-2038999143 PR Comment: https://git.openjdk.org/jextract/pull/240#issuecomment-2093766361 From thiago.sayao at gmail.com Fri May 10 13:34:12 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Fri, 10 May 2024 10:34:12 -0300 Subject: I am very pleased with jextract Message-ID: Hi, I've been using jextract and the FFM api for some days. It's great! I did Wayland (the linux desktop compositor protocol) bindings in record time. It would take me a very long time if JNI was involved (and it would be a pain). Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri May 10 14:01:07 2024 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 10 May 2024 15:01:07 +0100 Subject: I am very pleased with jextract In-Reply-To: References: Message-ID: Thanks Thiago. Positive feedback is something rare to come by - as most online discussions tend to be negatively biased (e.g. one only writes when there's something that doesn't quite work). So, thanks for taking the time to write this message :-) Cheers Maurizio On 10/05/2024 14:34, Thiago Milczarek Say?o wrote: > Hi, > > I've been using jextract and the FFM api for some days. > It's great! > > I did Wayland (the linux desktop compositor protocol) bindings in > record time. > > It would take me a very long time if JNI was involved (and it would be > a pain). > > Thanks! > > > > From wo6980 at gmail.com Mon May 13 12:20:31 2024 From: wo6980 at gmail.com (Oliver Weiler) Date: Mon, 13 May 2024 14:20:31 +0200 Subject: Please put jextract scripts under bin/ Message-ID: Hi everybody! First of all, great work on the 22 release! I was so excited that the java binaries were moved into the runtime/ folder. But now the jextract script are in the root directory of the archive, making jextract unable to be published via SDKMAN!, as SDKMAN! requires the binaries to be found under $ROOT/bin. Would it be possible to move them into the bin/ folder, similar to the way it was done in previous releases? Best regards, Oliver Weiler, SDKMAN! core contributor -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Mon May 13 12:58:04 2024 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 13 May 2024 13:58:04 +0100 Subject: Please put jextract scripts under bin/ In-Reply-To: References: Message-ID: <1b44bb97-a73a-4118-bbb6-7bee64dabd74@oracle.com> Hi Oliver, I believe it should be possible to do that, I did not understand that would have been problematic. Cheers Maurizio On 13/05/2024 13:20, Oliver Weiler wrote: > Hi everybody! > > First of all, great work on the 22 release! I was so excited that the > java binaries were moved into the runtime/ folder. > > But now the jextract script are in the root directory of the archive, > making jextract unable to be published via SDKMAN!, as SDKMAN! > requires the binaries to be found under $ROOT/bin. > > Would it be possible to move them into the bin/ folder, similar to the > way it was done in previous releases? > > Best regards, > Oliver Weiler, SDKMAN! core contributor From mcimadamore at openjdk.org Mon May 13 13:27:54 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 13 May 2024 13:27:54 GMT Subject: RFR: 7903723: Jextract binary should live in a bin folder Message-ID: <4fmqd12wL1tmdYfV7kMGDYG96cHe3bDcvlqZRIenvdw=.1fedcd1c-d131-41dd-ab7f-18ee32d85759@github.com> 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 From duke at openjdk.org Tue May 14 17:20:24 2024 From: duke at openjdk.org (Brayan Munoz V.) Date: Tue, 14 May 2024 17:20:24 GMT Subject: RFR: Reference latest JEP of FFM API. Message-ID: 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/b4da3284d41863af47d4a36b5829849b27cd47f4/README.md?plain=1#L3 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 From mcimadamore at openjdk.org Tue May 14 17:24:14 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 14 May 2024 17:24:14 GMT Subject: RFR: Reference latest JEP of FFM API. In-Reply-To: References: Message-ID: On Tue, 14 May 2024 17:15:37 GMT, Brayan Munoz V. wrote: > 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/b4da3284d41863af47d4a36b5829849b27cd47f4/README.md?plain=1#L3 > > 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. Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jextract/pull/243#pullrequestreview-2056001105 From Bernd_Goetz at swissre.com Wed May 15 12:03:37 2024 From: Bernd_Goetz at swissre.com (=?iso-8859-1?Q?Bernd_G=F6tz?=) Date: Wed, 15 May 2024 12:03:37 +0000 Subject: Bundled Oracle JRE Message-ID: Hi All, my organization complains about my jextract installation on my laptop - they find an Oracle JRE with a (TM) statement. $ c:\srdev\lds\packages\jextract-22\runtime\bin\java --version java 22 2024-03-19 Java(TM) SE Runtime Environment (build 22+35-2369) Java HotSpot(TM) 64-Bit Server VM (build 22+35-2369, mixed mode) The problem with this is that Oracle is hunting down all its customers for Java licensing, I'm sure everybody here is aware of that. I'm planning to use OpenJDK 22 and build the thing myself. Is it possible to get the binary switched to OpenJDK 22, too? Anything speaking against this? Br, Bernd This e-mail, including attachments, is intended for the person(s) or company(s) named and may contain confidential and/or legally privileged information. Unauthorized disclosure, copying or use of this information may be unlawful and is prohibited. If you are not the intended recipient, please delete this message and notify the sender. All incoming and outgoing e-mail messages are stored in the Swiss Re Electronic Message Repository. If you do not wish the retention of potentially private e-mails by Swiss Re, we strongly advise you not to use the Swiss Re e-mail account for any private, non-business related communications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jr at qsm.co.il Wed May 15 13:13:08 2024 From: jr at qsm.co.il (Jonathan Rosenne) Date: Wed, 15 May 2024 13:13:08 +0000 Subject: jextract warnings Message-ID: Intellij IDEA reports several warnings with the code generated by jextract. How difficult would it be to improve it? Of course I could let IDEA fix these warnings but I am not sure this is a good idea. The most common ones in my case are: 1. The final is superfluous: /** * The layout of this struct */ public static final GroupLayout layout() { return $LAYOUT; } 1. Field may be final private static long[] iv$DIMS = { 8 }; 1. Many classes have unused imports Best Regards, Jonathan Rosenne -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed May 15 13:15:40 2024 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 15 May 2024 14:15:40 +0100 Subject: Bundled Oracle JRE In-Reply-To: References: Message-ID: <836912fa-75ea-448a-852f-2d7f0852cddb@oracle.com> That's a good point, and it should not happen. E.g. the bundled RE _is_ an openjdk build. There must be some issue in the script we use to build the binaries. We'll take a look. Cheers Maurizio On 15/05/2024 13:03, Bernd G?tz wrote: > > Hi All, > > my organization complains about my jextract installation on my laptop > ? they find an Oracle JRE with a (TM) statement. > > $ c:\srdev\lds\packages\jextract-22\runtime\bin\java --version > > java 22 2024-03-19 > > Java(TM) SE Runtime Environment (build 22+35-2369) > > Java HotSpot(TM) 64-Bit Server VM (build 22+35-2369, mixed mode) > > The problem with this is that Oracle is hunting down all its customers > for Java licensing, I'm sure everybody here is aware of that. > > I'm planning to use OpenJDK 22 and build the thing myself. Is it > possible to get the binary switched to OpenJDK 22, too? Anything > speaking against this? > > Br, > > Bernd > > > This e-mail, including attachments, is intended for the person(s) or > company(s) named and may contain confidential and/or legally > privileged information. Unauthorized disclosure, copying or use of > this information may be unlawful and is prohibited. If you are not the > intended recipient, please delete this message and notify the sender. > All incoming and outgoing e-mail messages are stored in the Swiss Re > Electronic Message Repository. If you do not wish the retention of > potentially private e-mails by Swiss Re, we strongly advise you not to > use the Swiss Re e-mail account for any private, non-business related > communications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed May 15 13:17:47 2024 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 15 May 2024 14:17:47 +0100 Subject: jextract warnings In-Reply-To: References: Message-ID: <7c1939a8-49a5-4da2-9716-73e2c40d9662@oracle.com> Hi Jonathan, it would be relatively easy to fix the first two. Harder to fix the latter, given jextract uses a canned set of imports for all files it generates. I'm happy to help if you want to contribute a PR. The classes generating the output are called XYZBuilder. E.g. structs are generated by StructBuilder class, so it should be easy to find what you are looking for. Cheers Maurizio On 15/05/2024 14:13, Jonathan Rosenne wrote: > > Intellij IDEA reports several warnings with the code generated by > jextract. How difficult would it be to improve it? Of course I could > let IDEA fix these warnings but I am not sure this is a good idea. > > The most common ones in my case are: > > 1. The final is superfluous: > > ???/** > > ???? * The layout of this struct > > */ > > ??? public static final GroupLayout layout() { > > return $LAYOUT; > > } > > 2. Field may be final > > private static long[] iv$DIMS = { 8 }; > > 3. Many classes have unused imports > > Best Regards, > > Jonathan Rosenne > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jr at qsm.co.il Wed May 15 13:37:54 2024 From: jr at qsm.co.il (Jonathan Rosenne) Date: Wed, 15 May 2024 13:37:54 +0000 Subject: jextract warnings In-Reply-To: <7c1939a8-49a5-4da2-9716-73e2c40d9662@oracle.com> References: <7c1939a8-49a5-4da2-9716-73e2c40d9662@oracle.com> Message-ID: Dear Maurizio, I guessed so. I have no experience with open source and PR, but would not object to learn. Never too late. Point me to some spec. Best Regards, Jonathan Rosenne From: Maurizio Cimadamore Sent: Wednesday, May 15, 2024 4:18 PM To: Jonathan Rosenne ; jextract-dev at openjdk.org Subject: Re: jextract warnings Hi Jonathan, it would be relatively easy to fix the first two. Harder to fix the latter, given jextract uses a canned set of imports for all files it generates. I'm happy to help if you want to contribute a PR. The classes generating the output are called XYZBuilder. E.g. structs are generated by StructBuilder class, so it should be easy to find what you are looking for. Cheers Maurizio On 15/05/2024 14:13, Jonathan Rosenne wrote: Intellij IDEA reports several warnings with the code generated by jextract. How difficult would it be to improve it? Of course I could let IDEA fix these warnings but I am not sure this is a good idea. The most common ones in my case are: 1. The final is superfluous: /** * The layout of this struct */ public static final GroupLayout layout() { return $LAYOUT; } 1. Field may be final private static long[] iv$DIMS = { 8 }; 1. Many classes have unused imports Best Regards, Jonathan Rosenne -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Wed May 15 13:41:38 2024 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 15 May 2024 14:41:38 +0100 Subject: jextract warnings In-Reply-To: References: <7c1939a8-49a5-4da2-9716-73e2c40d9662@oracle.com> Message-ID: <65ef8f7e-2cf7-498d-a7c3-37f5f9e39a96@oracle.com> Hi, the openjdk developer guide is here: https://openjdk.org/guide/#i-have-a-patch-what-do-i-do More info on how JDK uses git/github can be found here https://wiki.openjdk.org/display/SKARA Maurizio On 15/05/2024 14:37, Jonathan Rosenne wrote: > > Dear Maurizio, > > I guessed so. > > I have no experience with open source and PR, but would not object to > learn. Never too late. Point me to some spec. > > Best Regards, > > Jonathan Rosenne > > *From:*Maurizio Cimadamore > *Sent:* Wednesday, May 15, 2024 4:18 PM > *To:* Jonathan Rosenne ; jextract-dev at openjdk.org > *Subject:* Re: jextract warnings > > Hi Jonathan, > it would be relatively easy to fix the first two. Harder to fix the > latter, given jextract uses a canned set of imports for all files it > generates. > > I'm happy to help if you want to contribute a PR. The classes > generating the output are called XYZBuilder. E.g. structs are > generated by StructBuilder class, so it should be easy to find what > you are looking for. > > Cheers > Maurizio > > On 15/05/2024 14:13, Jonathan Rosenne wrote: > > Intellij IDEA reports several warnings with the code generated by > jextract. How difficult would it be to improve it? Of course I > could let IDEA fix these warnings but I am not sure this is a good > idea. > > The most common ones in my case are: > > 1. The final is superfluous: > > ???/** > > * The layout of this struct > > */ > > public static final GroupLayout layout() { > > return $LAYOUT; > > } > > 2. Field may be final > > private static long[] iv$DIMS = { 8 }; > > 3. Many classes have unused imports > > Best Regards, > > Jonathan Rosenne > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nbenalla at openjdk.org Mon May 20 09:26:25 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 20 May 2024 09:26:25 GMT Subject: RFR: 7903727: Remove the reliance on String Templates feature Message-ID: <4Kshzn9LqSROMDpKW6keTHiToz_0C1rkDsQWVHwAjxI=.f1865549-488e-4488-82a2-09c768663c53@github.com> 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 From mcimadamore at openjdk.org Mon May 20 09:54:12 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 20 May 2024 09:54:12 GMT Subject: RFR: 7903727: Remove the reliance on String Templates feature In-Reply-To: <4Kshzn9LqSROMDpKW6keTHiToz_0C1rkDsQWVHwAjxI=.f1865549-488e-4488-82a2-09c768663c53@github.com> References: <4Kshzn9LqSROMDpKW6keTHiToz_0C1rkDsQWVHwAjxI=.f1865549-488e-4488-82a2-09c768663c53@github.com> Message-ID: On Mon, 20 May 2024 09:17:22 GMT, Nizar Benalla wrote: > 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. src/main/java/org/openjdk/jextract/impl/ClassSourceBuilder.java line 145: > 143: > 144: final void emitDefaultConstructor() { > 145: appendIndentedLines(String.format(""" Suggestion - tweak the `appendIndentedLines` to call `String::format` inside that method, so that all clients don't have to call `String::format` manually from outside. src/main/java/org/openjdk/jextract/impl/ClassSourceBuilder.java line 193: > 191: case Primitive p -> primitiveLayoutString(p, align); > 192: case Declared d when Utils.isEnum(d) -> layoutString(((Constant)d.tree().members().get(0)).type(), align); > 193: case Declared d when Utils.isStructOrUnion(d) -> alignIfNeeded(String.format("%s.layout()", JavaName.getFullNameOrThrow(d.tree())), ClangAlignOf.getOrThrow(d.tree()) / 8, align); Same thing here - if all calls to `alignIfNeeded` end up with `String::format`, considering moving `String::format` there ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/244#discussion_r1606529144 PR Review Comment: https://git.openjdk.org/jextract/pull/244#discussion_r1606530581 From mcimadamore at openjdk.org Mon May 20 10:05:15 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 20 May 2024 10:05:15 GMT Subject: RFR: 7903727: Remove the reliance on String Templates feature In-Reply-To: <4Kshzn9LqSROMDpKW6keTHiToz_0C1rkDsQWVHwAjxI=.f1865549-488e-4488-82a2-09c768663c53@github.com> References: <4Kshzn9LqSROMDpKW6keTHiToz_0C1rkDsQWVHwAjxI=.f1865549-488e-4488-82a2-09c768663c53@github.com> Message-ID: <49VUCXStptaohKn19actUm4-7J7_xTQT9N3B6gt7Mms=.f7276311-48a6-4bf0-999f-c3d2e39ef390@github.com> On Mon, 20 May 2024 09:17:22 GMT, Nizar Benalla wrote: > 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. src/main/java/org/openjdk/jextract/impl/HeaderFileBuilder.java line 410: > 408: return %s.SEGMENT.get(%s.LAYOUT, 0L); > 409: } > 410: """, type.getSimpleName(), javaName, holderClass, holderClass)); In these cases, an ad-hoc formatter might work as well. Similar to `MessageFormat` which allows the user to pass arguments with indices like `{0}` and `{1}`. Example: jshell> MessageFormat.format("{0} {0} {1}", "Hello", "World!"); $7 ==> "Hello Hello World!" ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/244#discussion_r1606541914 From mcimadamore at openjdk.org Mon May 20 10:13:13 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 20 May 2024 10:13:13 GMT Subject: RFR: 7903727: Remove the reliance on String Templates feature In-Reply-To: <49VUCXStptaohKn19actUm4-7J7_xTQT9N3B6gt7Mms=.f7276311-48a6-4bf0-999f-c3d2e39ef390@github.com> References: <4Kshzn9LqSROMDpKW6keTHiToz_0C1rkDsQWVHwAjxI=.f1865549-488e-4488-82a2-09c768663c53@github.com> <49VUCXStptaohKn19actUm4-7J7_xTQT9N3B6gt7Mms=.f7276311-48a6-4bf0-999f-c3d2e39ef390@github.com> Message-ID: On Mon, 20 May 2024 10:02:09 GMT, Maurizio Cimadamore wrote: >> 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. > > src/main/java/org/openjdk/jextract/impl/HeaderFileBuilder.java line 410: > >> 408: return %s.SEGMENT.get(%s.LAYOUT, 0L); >> 409: } >> 410: """, type.getSimpleName(), javaName, holderClass, holderClass)); > > In these cases, an ad-hoc formatter might work as well. Similar to `MessageFormat` which allows the user to pass arguments with indices like `{0}` and `{1}`. Example: > > > jshell> MessageFormat.format("{0} {0} {1}", "Hello", "World!"); > $7 ==> "Hello Hello World!" This might also help improving readability for messages containing lots of `%s` (as at least you can look at the number being referenced, and then count the arguments passed to the `format` method to find the one you want. Also, this allows to refactor code more robustly - e.g. you can pass _new_ trailing parameters to `format`, and maybe have them used _before_ the others: jshell> MessageFormat.format("{0} {2} {0} {1}", "Hello", "World!", "Maurizio"); $7 ==> "Hello Maurizio Hello World!" E.g. thanks to explicit numbers, the formatting is not tied to the order in which the arguments are passed to the `format` method. ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/244#discussion_r1606545826 From mcimadamore at openjdk.org Mon May 20 10:13:13 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 20 May 2024 10:13:13 GMT Subject: RFR: 7903727: Remove the reliance on String Templates feature In-Reply-To: <4Kshzn9LqSROMDpKW6keTHiToz_0C1rkDsQWVHwAjxI=.f1865549-488e-4488-82a2-09c768663c53@github.com> References: <4Kshzn9LqSROMDpKW6keTHiToz_0C1rkDsQWVHwAjxI=.f1865549-488e-4488-82a2-09c768663c53@github.com> Message-ID: On Mon, 20 May 2024 09:17:22 GMT, Nizar Benalla wrote: > 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. src/main/java/org/openjdk/jextract/impl/HeaderFileBuilder.java line 573: > 571: emitDocComment(declaration); > 572: appendLines(String.format(""" > 573: public static %s %s() { Why the negative indentation here? (also in the code below) src/main/java/org/openjdk/jextract/impl/StructBuilder.java line 325: > 323: } > 324: """, > 325: arrayParam, arrayParam, arrayParam, arrayParam, arrayParam)); In this case, using a `MessageFormat`-like approach is particularly convenient (as there would be just one param) ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/244#discussion_r1606547765 PR Review Comment: https://git.openjdk.org/jextract/pull/244#discussion_r1606550761 From mcimadamore at openjdk.org Mon May 20 10:16:24 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 20 May 2024 10:16:24 GMT Subject: RFR: 7903727: Remove the reliance on String Templates feature In-Reply-To: <4Kshzn9LqSROMDpKW6keTHiToz_0C1rkDsQWVHwAjxI=.f1865549-488e-4488-82a2-09c768663c53@github.com> References: <4Kshzn9LqSROMDpKW6keTHiToz_0C1rkDsQWVHwAjxI=.f1865549-488e-4488-82a2-09c768663c53@github.com> Message-ID: <7gnrGN190eVgaOJh9XyARqVu7T_CQB54JJH4ztePkKM=.5e795a8d-e78c-4505-a4ae-f5c39ab53351@github.com> On Mon, 20 May 2024 09:17:22 GMT, Nizar Benalla wrote: > 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. This is a good like-for-like refactoring. I've left comments to improve readability of the code a bit. I think the comments are of two kinds: * we could move String::format deeper in the call chain, so that call sites could look "cleaner" * we could use a different way to format messages, more similar to `MessageFormat` where arguments have indices that can be used in the format message (so they can be repeated, reordered, etc.). Addressing the latter comment is not strictly required as part of this PR, but I believe we might need to do something along these lines to restore at least some level of readability. ------------- PR Review: https://git.openjdk.org/jextract/pull/244#pullrequestreview-2065867189 From nbenalla at openjdk.org Mon May 20 11:08:37 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 20 May 2024 11:08:37 GMT Subject: RFR: 7903727: Remove the reliance on String Templates feature [v2] In-Reply-To: <4Kshzn9LqSROMDpKW6keTHiToz_0C1rkDsQWVHwAjxI=.f1865549-488e-4488-82a2-09c768663c53@github.com> References: <4Kshzn9LqSROMDpKW6keTHiToz_0C1rkDsQWVHwAjxI=.f1865549-488e-4488-82a2-09c768663c53@github.com> Message-ID: > 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. Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: - Fix some indentations - Tweak `alignIfNeeded` ------------- Changes: - all: https://git.openjdk.org/jextract/pull/244/files - new: https://git.openjdk.org/jextract/pull/244/files/d5e9ffb1..6adcab3e Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=244&range=01 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=244&range=00-01 Stats: 33 lines in 2 files changed: 1 ins; 0 del; 32 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 From nbenalla at openjdk.org Mon May 20 11:08:37 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 20 May 2024 11:08:37 GMT Subject: RFR: 7903727: Remove the reliance on String Templates feature In-Reply-To: <4Kshzn9LqSROMDpKW6keTHiToz_0C1rkDsQWVHwAjxI=.f1865549-488e-4488-82a2-09c768663c53@github.com> References: <4Kshzn9LqSROMDpKW6keTHiToz_0C1rkDsQWVHwAjxI=.f1865549-488e-4488-82a2-09c768663c53@github.com> Message-ID: On Mon, 20 May 2024 09:17:22 GMT, Nizar Benalla wrote: > 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. Thanks for the comments! ------------- PR Comment: https://git.openjdk.org/jextract/pull/244#issuecomment-2120218100 From nbenalla at openjdk.org Mon May 20 11:08:37 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 20 May 2024 11:08:37 GMT Subject: RFR: 7903727: Remove the reliance on String Templates feature [v2] In-Reply-To: References: <4Kshzn9LqSROMDpKW6keTHiToz_0C1rkDsQWVHwAjxI=.f1865549-488e-4488-82a2-09c768663c53@github.com> Message-ID: On Mon, 20 May 2024 09:50:20 GMT, Maurizio Cimadamore wrote: >> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix some indentations >> - Tweak `alignIfNeeded` > > src/main/java/org/openjdk/jextract/impl/ClassSourceBuilder.java line 145: > >> 143: >> 144: final void emitDefaultConstructor() { >> 145: appendIndentedLines(String.format(""" > > Suggestion - tweak the `appendIndentedLines` to call `String::format` inside that method, so that all clients don't have to call `String::format` manually from outside. Would this work? Before appendIndentedLines(String.format(""" private static final MethodHandle %s = %s.sliceHandle(%s); """, arrayHandleName, fieldLayoutName, path)); After void appendIndentedLines(String s, String... args) { sb.appendIndentedLines(String.format(s,args)); } and the call would look like appendIndentedLines("private static final MethodHandle %s = %s.sliceHandle(%s);" , arrayHandleName, fieldLayoutName, path)); probably would create a new method rather than remove the old one > src/main/java/org/openjdk/jextract/impl/ClassSourceBuilder.java line 193: > >> 191: case Primitive p -> primitiveLayoutString(p, align); >> 192: case Declared d when Utils.isEnum(d) -> layoutString(((Constant)d.tree().members().get(0)).type(), align); >> 193: case Declared d when Utils.isStructOrUnion(d) -> alignIfNeeded(String.format("%s.layout()", JavaName.getFullNameOrThrow(d.tree())), ClangAlignOf.getOrThrow(d.tree()) / 8, align); > > Same thing here - if all calls to `alignIfNeeded` end up with `String::format`, considering moving `String::format` there Fixed in [991ad7c](https://github.com/openjdk/jextract/pull/244/commits/991ad7c1a6f2c13aa9c7860cf654432e8bc70bac) > src/main/java/org/openjdk/jextract/impl/HeaderFileBuilder.java line 573: > >> 571: emitDocComment(declaration); >> 572: appendLines(String.format(""" >> 573: public static %s %s() { > > Why the negative indentation here? (also in the code below) Fixed in [6adcab3](https://github.com/openjdk/jextract/pull/244/commits/6adcab3e23db3e03ee08a05889e23de31d088d2d), I think I didn't see them in the diff. ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/244#discussion_r1606603835 PR Review Comment: https://git.openjdk.org/jextract/pull/244#discussion_r1606604750 PR Review Comment: https://git.openjdk.org/jextract/pull/244#discussion_r1606604443 From jvernee at openjdk.org Mon May 20 16:54:14 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 20 May 2024 16:54:14 GMT Subject: RFR: 7903727: Remove the reliance on String Templates feature [v2] In-Reply-To: <7gnrGN190eVgaOJh9XyARqVu7T_CQB54JJH4ztePkKM=.5e795a8d-e78c-4505-a4ae-f5c39ab53351@github.com> References: <4Kshzn9LqSROMDpKW6keTHiToz_0C1rkDsQWVHwAjxI=.f1865549-488e-4488-82a2-09c768663c53@github.com> <7gnrGN190eVgaOJh9XyARqVu7T_CQB54JJH4ztePkKM=.5e795a8d-e78c-4505-a4ae-f5c39ab53351@github.com> Message-ID: On Mon, 20 May 2024 10:13:53 GMT, Maurizio Cimadamore wrote: > we could use a different way to format messages, more similar to MessageFormat where arguments have indices that can be used in the format message (so they can be repeated, reordered, etc.). `String.format` also supports referencing arguments by index, e.g. `String.format("%2$s %1$s", "A", "B")` would produce `"B A"`, and the same argument can be referenced multiple times as well. I suggest we use that for the longer text blocks with multiple embedded values. ------------- PR Comment: https://git.openjdk.org/jextract/pull/244#issuecomment-2120827040 From mcimadamore at openjdk.org Mon May 20 17:02:15 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 20 May 2024 17:02:15 GMT Subject: RFR: 7903727: Remove the reliance on String Templates feature [v2] In-Reply-To: References: <4Kshzn9LqSROMDpKW6keTHiToz_0C1rkDsQWVHwAjxI=.f1865549-488e-4488-82a2-09c768663c53@github.com> <7gnrGN190eVgaOJh9XyARqVu7T_CQB54JJH4ztePkKM=.5e795a8d-e78c-4505-a4ae-f5c39ab53351@github.com> Message-ID: On Mon, 20 May 2024 16:51:00 GMT, Jorn Vernee wrote: > > we could use a different way to format messages, more similar to MessageFormat where arguments have indices that can be used in the format message (so they can be repeated, reordered, etc.). > > `String.format` also supports referencing arguments by index, e.g. `String.format("%2$s %1$s", "A", "B")` would produce `"B A"`, and the same argument can be referenced multiple times as well. I suggest we use that for the longer text blocks with multiple embedded values. Good point, I never used this escape hatch :-) I wonder though if readability of that is good enough. The problem with message format of course is need to escape `{` which are quite common in code... So perhaps we can use the trick suggested by @JornVernee in selected places and maybe tinker later (e.g. maybe come up with our own templating solution, if we really need that). ------------- PR Comment: https://git.openjdk.org/jextract/pull/244#issuecomment-2120840188 From jvernee at openjdk.org Tue May 21 05:58:18 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 21 May 2024 05:58:18 GMT Subject: RFR: 7903723: Jextract binary should live in a bin folder In-Reply-To: <4fmqd12wL1tmdYfV7kMGDYG96cHe3bDcvlqZRIenvdw=.1fedcd1c-d131-41dd-ab7f-18ee32d85759@github.com> References: <4fmqd12wL1tmdYfV7kMGDYG96cHe3bDcvlqZRIenvdw=.1fedcd1c-d131-41dd-ab7f-18ee32d85759@github.com> Message-ID: On Mon, 13 May 2024 13:23:03 GMT, Maurizio Cimadamore wrote: > This PR reintroduces the `bin` folder for jextract launcher scripts. Marked as reviewed by jvernee (Committer). ------------- PR Review: https://git.openjdk.org/jextract/pull/242#pullrequestreview-2067602453 From mcimadamore at openjdk.org Tue May 21 08:44:14 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 21 May 2024 08:44:14 GMT Subject: Integrated: 7903723: Jextract binary should live in a bin folder In-Reply-To: <4fmqd12wL1tmdYfV7kMGDYG96cHe3bDcvlqZRIenvdw=.1fedcd1c-d131-41dd-ab7f-18ee32d85759@github.com> References: <4fmqd12wL1tmdYfV7kMGDYG96cHe3bDcvlqZRIenvdw=.1fedcd1c-d131-41dd-ab7f-18ee32d85759@github.com> Message-ID: On Mon, 13 May 2024 13:23:03 GMT, Maurizio Cimadamore wrote: > This PR reintroduces the `bin` folder for jextract launcher scripts. This pull request has now been integrated. Changeset: 87a9efd4 Author: Maurizio Cimadamore URL: https://git.openjdk.org/jextract/commit/87a9efd4dfccd2196adb165f8bcf89cf9abfd0b1 Stats: 11 lines in 3 files changed: 3 ins; 0 del; 8 mod 7903723: Jextract binary should live in a bin folder Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jextract/pull/242 From duke at openjdk.org Thu May 23 13:14:23 2024 From: duke at openjdk.org (Ana Maria Mihalceanu) Date: Thu, 23 May 2024 13:14:23 GMT Subject: RFR: Update macOS version of the OpenGL sample to match the current state of OpenGL/Glut on Mac Message-ID: 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/compile.sh) or [compilesource.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/compilesource.sh) will produce Java code that compiles. * attempting to run [run.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/run.sh) 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.(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/master/samples/opengl/compile_flags.txt)](https://github.com/openjdk/jextract/blob/master/samples/opengl/compile_flags.txt) * 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 From mcimadamore at openjdk.org Thu May 23 16:14:24 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 23 May 2024 16:14:24 GMT Subject: RFR: Update macOS version of the OpenGL sample to match the current state of OpenGL/Glut on Mac In-Reply-To: References: Message-ID: On Thu, 23 May 2024 11:36:59 GMT, Ana Maria Mihalceanu wrote: > 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/compile.sh) or [compilesource.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/compilesource.sh) will produce Java code that compiles. > * attempting to run [run.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/run.sh) 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.(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/master/samples/opengl/compile_flags.txt)](https://github.com/openjdk/jextract/blob/master/samples/opengl/compile_flags.txt) > * 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) Looks good - I'll leave the last word to @sundararajana as I don't have a macos to test it on :-) ------------- PR Comment: https://git.openjdk.org/jextract/pull/245#issuecomment-2127538918 From mcimadamore at openjdk.org Mon May 27 14:13:35 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 27 May 2024 14:13:35 GMT Subject: RFR: Remove duplicate copies of libclang on Linux Message-ID: <-Zv54YANidxiKjRnCUvepeyQ93ilAKki4EDnJCU9D6E=.86d07048-4264-4538-8be6-ca0bb476783a@github.com> 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 From jvernee at openjdk.org Mon May 27 14:18:15 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 27 May 2024 14:18:15 GMT Subject: RFR: Remove duplicate copies of libclang on Linux In-Reply-To: <-Zv54YANidxiKjRnCUvepeyQ93ilAKki4EDnJCU9D6E=.86d07048-4264-4538-8be6-ca0bb476783a@github.com> References: <-Zv54YANidxiKjRnCUvepeyQ93ilAKki4EDnJCU9D6E=.86d07048-4264-4538-8be6-ca0bb476783a@github.com> Message-ID: On Mon, 27 May 2024 14:09:51 GMT, Maurizio Cimadamore wrote: > 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). LGTM. Might want to test on mac as well? ------------- Marked as reviewed by jvernee (Committer). PR Review: https://git.openjdk.org/jextract/pull/246#pullrequestreview-2081035349 From mcimadamore at openjdk.org Mon May 27 14:20:38 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 27 May 2024 14:20:38 GMT Subject: RFR: Add support for bin folder in makefile Message-ID: <9NKESVi7RdP55ubCJp1JiJoJN6xb_j6b3lXHrD5AVoo=.ab1f5c9f-76ee-41fa-801b-ae642e463163@github.com> 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 From jvernee at openjdk.org Mon May 27 14:20:38 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 27 May 2024 14:20:38 GMT Subject: RFR: Add support for bin folder in makefile In-Reply-To: <9NKESVi7RdP55ubCJp1JiJoJN6xb_j6b3lXHrD5AVoo=.ab1f5c9f-76ee-41fa-801b-ae642e463163@github.com> References: <9NKESVi7RdP55ubCJp1JiJoJN6xb_j6b3lXHrD5AVoo=.ab1f5c9f-76ee-41fa-801b-ae642e463163@github.com> Message-ID: On Mon, 27 May 2024 14:14:02 GMT, Maurizio Cimadamore wrote: > 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. Marked as reviewed by jvernee (Committer). ------------- PR Review: https://git.openjdk.org/jextract/pull/247#pullrequestreview-2081037557 From mcimadamore at openjdk.org Mon May 27 14:32:14 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 27 May 2024 14:32:14 GMT Subject: RFR: Remove duplicate copies of libclang on Linux In-Reply-To: References: <-Zv54YANidxiKjRnCUvepeyQ93ilAKki4EDnJCU9D6E=.86d07048-4264-4538-8be6-ca0bb476783a@github.com> Message-ID: On Mon, 27 May 2024 14:15:51 GMT, Jorn Vernee wrote: > LGTM. Might want to test on mac as well? Yes. My understanding is that on macos, versioning with symlinks is not a thing. That said, I think there's an issue in the makefile: when we do the final `mv`, if the file doesn't exist, then `mv` will fail. ------------- PR Comment: https://git.openjdk.org/jextract/pull/246#issuecomment-2133601383 From mcimadamore at openjdk.org Mon May 27 14:33:27 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 27 May 2024 14:33:27 GMT Subject: RFR: Add support for bin folder in makefile [v2] In-Reply-To: <9NKESVi7RdP55ubCJp1JiJoJN6xb_j6b3lXHrD5AVoo=.ab1f5c9f-76ee-41fa-801b-ae642e463163@github.com> References: <9NKESVi7RdP55ubCJp1JiJoJN6xb_j6b3lXHrD5AVoo=.ab1f5c9f-76ee-41fa-801b-ae642e463163@github.com> Message-ID: <837NF7X4cfm0nVi5a2H-YX0JlS8PTd2wVU2bIcaS21g=.3c53b1b1-f182-4f8e-9dee-163a830b73c4@github.com> > 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. Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Set correct permissions for linux script, to mimic what gradle does ------------- Changes: - all: https://git.openjdk.org/jextract/pull/247/files - new: https://git.openjdk.org/jextract/pull/247/files/8c98876d..620fbd7b Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=247&range=01 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=247&range=00-01 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 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 From mcimadamore at openjdk.org Mon May 27 14:33:27 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 27 May 2024 14:33:27 GMT Subject: RFR: Add support for bin folder in makefile [v2] In-Reply-To: <837NF7X4cfm0nVi5a2H-YX0JlS8PTd2wVU2bIcaS21g=.3c53b1b1-f182-4f8e-9dee-163a830b73c4@github.com> References: <9NKESVi7RdP55ubCJp1JiJoJN6xb_j6b3lXHrD5AVoo=.ab1f5c9f-76ee-41fa-801b-ae642e463163@github.com> <837NF7X4cfm0nVi5a2H-YX0JlS8PTd2wVU2bIcaS21g=.3c53b1b1-f182-4f8e-9dee-163a830b73c4@github.com> Message-ID: <72o-WMzn6EvLam5UUGo2z4HanRlcY6vT0M_ZoL1nc0s=.d5ef5a15-259b-478b-a5b9-974b53771cfc@github.com> On Mon, 27 May 2024 14:30:34 GMT, Maurizio Cimadamore wrote: >> 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. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Set correct permissions for linux script, to mimic what gradle does make/Build.gmk line 90: > 88: $(CP) src/main/jextract "$(JEXTRACT_IMAGE_DIR)/bin" > 89: $(CP) src/main/jextract.bat "$(JEXTRACT_IMAGE_DIR)/bin" > 90: $(CHMOD) +x "$(JEXTRACT_IMAGE_DIR)/bin/jextract" This line is partly unrelated, but it does update the file permissions of the Linux shell, similarly to what happens on Gradle. ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/247#discussion_r1616130222 From mcimadamore at openjdk.org Mon May 27 14:36:23 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 27 May 2024 14:36:23 GMT Subject: RFR: Remove duplicate copies of libclang on Linux [v2] In-Reply-To: <-Zv54YANidxiKjRnCUvepeyQ93ilAKki4EDnJCU9D6E=.86d07048-4264-4538-8be6-ca0bb476783a@github.com> References: <-Zv54YANidxiKjRnCUvepeyQ93ilAKki4EDnJCU9D6E=.86d07048-4264-4538-8be6-ca0bb476783a@github.com> Message-ID: > 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). Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Only rename libclang.so. file if present ------------- Changes: - all: https://git.openjdk.org/jextract/pull/246/files - new: https://git.openjdk.org/jextract/pull/246/files/d3dd2031..1f09fa86 Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=246&range=01 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=246&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 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 From mcimadamore at openjdk.org Mon May 27 15:03:23 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 27 May 2024 15:03:23 GMT Subject: RFR: Remove duplicate copies of libclang on Linux [v3] In-Reply-To: <-Zv54YANidxiKjRnCUvepeyQ93ilAKki4EDnJCU9D6E=.86d07048-4264-4538-8be6-ca0bb476783a@github.com> References: <-Zv54YANidxiKjRnCUvepeyQ93ilAKki4EDnJCU9D6E=.86d07048-4264-4538-8be6-ca0bb476783a@github.com> Message-ID: > 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). Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: - Only tweak copy path for linux, not mac (gradle) - Tweak conditional move ------------- Changes: - all: https://git.openjdk.org/jextract/pull/246/files - new: https://git.openjdk.org/jextract/pull/246/files/1f09fa86..516bf35f Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=246&range=02 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=246&range=01-02 Stats: 2 lines in 2 files changed: 0 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 From jvernee at openjdk.org Mon May 27 15:54:12 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 27 May 2024 15:54:12 GMT Subject: RFR: Remove duplicate copies of libclang on Linux [v3] In-Reply-To: References: <-Zv54YANidxiKjRnCUvepeyQ93ilAKki4EDnJCU9D6E=.86d07048-4264-4538-8be6-ca0bb476783a@github.com> Message-ID: On Mon, 27 May 2024 15:03:23 GMT, Maurizio Cimadamore wrote: >> 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). > > Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: > > - Only tweak copy path for linux, not mac (gradle) > - Tweak conditional move Looks good. GHA failure on Windows is due to libclang crash ------------- Marked as reviewed by jvernee (Committer). PR Review: https://git.openjdk.org/jextract/pull/246#pullrequestreview-2081203742 From mcimadamore at openjdk.org Tue May 28 10:37:13 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 28 May 2024 10:37:13 GMT Subject: Integrated: Remove duplicate copies of libclang on Linux In-Reply-To: <-Zv54YANidxiKjRnCUvepeyQ93ilAKki4EDnJCU9D6E=.86d07048-4264-4538-8be6-ca0bb476783a@github.com> References: <-Zv54YANidxiKjRnCUvepeyQ93ilAKki4EDnJCU9D6E=.86d07048-4264-4538-8be6-ca0bb476783a@github.com> Message-ID: <6DtqOLvC7WhH8FhNMpA0LmdmjAxQjlGTNb92XQT5mZY=.35243130-f8a9-43b3-92d9-b6e469af1bef@github.com> On Mon, 27 May 2024 14:09:51 GMT, Maurizio Cimadamore wrote: > 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). This pull request has now been integrated. Changeset: 2fb93f96 Author: Maurizio Cimadamore URL: https://git.openjdk.org/jextract/commit/2fb93f965a3dc8ec8290a89527e9fa21c5907dd5 Stats: 18 lines in 3 files changed: 16 ins; 0 del; 2 mod Remove duplicate copies of libclang on Linux Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jextract/pull/246 From mcimadamore at openjdk.org Tue May 28 10:37:14 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 28 May 2024 10:37:14 GMT Subject: Integrated: Add support for bin folder in makefile In-Reply-To: <9NKESVi7RdP55ubCJp1JiJoJN6xb_j6b3lXHrD5AVoo=.ab1f5c9f-76ee-41fa-801b-ae642e463163@github.com> References: <9NKESVi7RdP55ubCJp1JiJoJN6xb_j6b3lXHrD5AVoo=.ab1f5c9f-76ee-41fa-801b-ae642e463163@github.com> Message-ID: <5Fzs75yxA04GiKdez8YMaZNfDOD53VjNF4Jz_Mzicrs=.ab05a897-9963-4a49-b8b2-cb3296ee4c01@github.com> On Mon, 27 May 2024 14:14:02 GMT, Maurizio Cimadamore wrote: > 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. This pull request has now been integrated. Changeset: 926070f9 Author: Maurizio Cimadamore URL: https://git.openjdk.org/jextract/commit/926070f9eea83a0cee916240052bf04d5f2312a6 Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod Add support for bin folder in makefile Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jextract/pull/247 From maurizio.cimadamore at oracle.com Wed May 29 20:53:11 2024 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 29 May 2024 21:53:11 +0100 Subject: new jextract builds Message-ID: 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 From sundar at openjdk.org Thu May 30 07:22:17 2024 From: sundar at openjdk.org (Athijegannathan Sundararajan) Date: Thu, 30 May 2024 07:22:17 GMT Subject: RFR: Update macOS version of the OpenGL sample to match the current state of OpenGL/Glut on Mac In-Reply-To: References: Message-ID: On Thu, 23 May 2024 11:36:59 GMT, Ana Maria Mihalceanu wrote: > 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/compile.sh) or [compilesource.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/compilesource.sh) will produce Java code that compiles. > * attempting to run [run.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/run.sh) 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.(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/master/samples/opengl/compile_flags.txt)](https://github.com/openjdk/jextract/blob/master/samples/opengl/compile_flags.txt) > * 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) LGTM Please add the following line to the compilesource.sh script javac --source=22 -d . opengl/*.java jextract only generates source files. we need to compile before using run.sh. The comtpilesource.sh scripts in all other samples have javac instruction. ------------- Marked as reviewed by sundar (Committer). PR Review: https://git.openjdk.org/jextract/pull/245#pullrequestreview-2087432695 PR Comment: https://git.openjdk.org/jextract/pull/245#issuecomment-2138845839 From duke at openjdk.org Thu May 30 07:30:31 2024 From: duke at openjdk.org (Ana Maria Mihalceanu) Date: Thu, 30 May 2024 07:30:31 GMT Subject: RFR: Update macOS version of the OpenGL sample to match the current state of OpenGL/Glut on Mac [v2] In-Reply-To: References: Message-ID: > 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/compile.sh) or [compilesource.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/compilesource.sh) will produce Java code that compiles. > * attempting to run [run.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/run.sh) 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.(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/master/samples/opengl/compile_flags.txt)](https://github.com/openjdk/jextract/blob/master/samples/opengl/compile_flags.txt) > * 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) Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision: Add source 22 and class output directory. ------------- Changes: - all: https://git.openjdk.org/jextract/pull/245/files - new: https://git.openjdk.org/jextract/pull/245/files/536a0bb7..e1c67362 Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=245&range=01 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=245&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 From sundar at openjdk.org Thu May 30 07:30:31 2024 From: sundar at openjdk.org (Athijegannathan Sundararajan) Date: Thu, 30 May 2024 07:30:31 GMT Subject: RFR: Update macOS version of the OpenGL sample to match the current state of OpenGL/Glut on Mac In-Reply-To: References: Message-ID: On Thu, 30 May 2024 07:19:32 GMT, Athijegannathan Sundararajan wrote: >> 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/compile.sh) or [compilesource.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/compilesource.sh) will produce Java code that compiles. >> * attempting to run [run.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/run.sh) 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.(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/master/samples/opengl/compile_flags.txt)](https://github.com/openjdk/jextract/blob/master/samples/opengl/compile_flags.txt) >> * 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) > > Please add the following line to the compilesource.sh script > > javac --source=22 -d . opengl/*.java > > jextract only generates source files. we need to compile before using run.sh. The comtpilesource.sh scripts in all other samples have javac instruction. > Looks good - I'll leave the last word to @sundararajana as I don't have a macos to test it on :-) I verified that the sample works fine on my MacOS/intel machine after applying the current patch ------------- PR Comment: https://git.openjdk.org/jextract/pull/245#issuecomment-2138855232 From duke at openjdk.org Thu May 30 07:47:41 2024 From: duke at openjdk.org (Ana Maria Mihalceanu) Date: Thu, 30 May 2024 07:47:41 GMT Subject: RFR: Update macOS version of the OpenGL sample to match the current state of OpenGL/Glut on Mac [v3] In-Reply-To: References: Message-ID: > 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/compile.sh) or [compilesource.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/compilesource.sh) will produce Java code that compiles. > * attempting to run [run.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/run.sh) 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.(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/master/samples/opengl/compile_flags.txt)](https://github.com/openjdk/jextract/blob/master/samples/opengl/compile_flags.txt) > * 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) Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision: Add a newline at the end of file. ------------- Changes: - all: https://git.openjdk.org/jextract/pull/245/files - new: https://git.openjdk.org/jextract/pull/245/files/e1c67362..f7256b6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=245&range=02 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=245&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 From sundar at openjdk.org Thu May 30 13:26:14 2024 From: sundar at openjdk.org (Athijegannathan Sundararajan) Date: Thu, 30 May 2024 13:26:14 GMT Subject: RFR: Update macOS version of the OpenGL sample to match the current state of OpenGL/Glut on Mac [v3] In-Reply-To: References: Message-ID: On Thu, 30 May 2024 07:47:41 GMT, Ana Maria Mihalceanu wrote: >> 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/compile.sh) or [compilesource.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/compilesource.sh) will produce Java code that compiles. >> * attempting to run [run.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/run.sh) 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.(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/master/samples/opengl/compile_flags.txt)](https://github.com/openjdk/jextract/blob/master/samples/opengl/compile_flags.txt) >> * 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) > > Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision: > > Add a newline at the end of file. The -l paths in compilesource.sh may be changed as follows: $ cat compilesource.sh jextract -t opengl -l :/System/Library/Frameworks/GLUT.framework/GLUT \ -l :/System/Library/Frameworks/OpenGL.framework/OpenGL \ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/GLUT.framework/Headers/glut.h javac --source=22 -d . opengl/*.java ------------- PR Comment: https://git.openjdk.org/jextract/pull/245#issuecomment-2139550108 From duke at openjdk.org Thu May 30 14:21:36 2024 From: duke at openjdk.org (Ana Maria Mihalceanu) Date: Thu, 30 May 2024 14:21:36 GMT Subject: RFR: Update macOS version of the OpenGL sample to match the current state of OpenGL/Glut on Mac [v3] In-Reply-To: References: Message-ID: On Thu, 30 May 2024 07:47:41 GMT, Ana Maria Mihalceanu wrote: >> 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/compile.sh) or [compilesource.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/compilesource.sh) will produce Java code that compiles. >> * attempting to run [run.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/run.sh) 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.(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/master/samples/opengl/compile_flags.txt)](https://github.com/openjdk/jextract/blob/master/samples/opengl/compile_flags.txt) >> * 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) > > Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision: > > Add a newline at the end of file. Great finding ? ! Thank you. I shortened the path, tested and delivered a new commit. ------------- PR Comment: https://git.openjdk.org/jextract/pull/245#issuecomment-2139662264 From duke at openjdk.org Thu May 30 14:21:36 2024 From: duke at openjdk.org (Ana Maria Mihalceanu) Date: Thu, 30 May 2024 14:21:36 GMT Subject: RFR: Update macOS version of the OpenGL sample to match the current state of OpenGL/Glut on Mac [v4] In-Reply-To: References: Message-ID: > 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/compile.sh) or [compilesource.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/compilesource.sh) will produce Java code that compiles. > * attempting to run [run.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/run.sh) 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.(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/master/samples/opengl/compile_flags.txt)](https://github.com/openjdk/jextract/blob/master/samples/opengl/compile_flags.txt) > * 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) Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision: Shorten the path to GLUT and OpenGL. ------------- Changes: - all: https://git.openjdk.org/jextract/pull/245/files - new: https://git.openjdk.org/jextract/pull/245/files/f7256b6a..a28666a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=245&range=03 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=245&range=02-03 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 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 From mcimadamore at openjdk.org Thu May 30 14:28:14 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 30 May 2024 14:28:14 GMT Subject: RFR: Update macOS version of the OpenGL sample to match the current state of OpenGL/Glut on Mac [v4] In-Reply-To: References: Message-ID: On Thu, 30 May 2024 14:21:36 GMT, Ana Maria Mihalceanu wrote: >> 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/compile.sh) or [compilesource.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/compilesource.sh) will produce Java code that compiles. >> * attempting to run [run.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/run.sh) 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.(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/master/samples/opengl/compile_flags.txt)](https://github.com/openjdk/jextract/blob/master/samples/opengl/compile_flags.txt) >> * 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) > > Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision: > > Shorten the path to GLUT and OpenGL. Looks great - thanks! ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jextract/pull/245#pullrequestreview-2088439122 From mik3hall at gmail.com Thu May 30 18:50:12 2024 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 30 May 2024 13:50:12 -0500 Subject: MacOS Message-ID: <0FECE078-27E4-4E17-8D94-493496BABE90@gmail.com> 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 at 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 at 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? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bernd_Goetz at swissre.com Thu May 30 20:48:27 2024 From: Bernd_Goetz at swissre.com (=?iso-8859-1?Q?Bernd_G=F6tz?=) Date: Thu, 30 May 2024 20:48:27 +0000 Subject: new jextract builds In-Reply-To: References: Message-ID: Very nice. Thanks for the JDK replacement, Maurizio! -----Original Message----- From: jextract-dev On Behalf Of Maurizio Cimadamore Sent: Mittwoch, 29. Mai 2024 22:53 To: jextract-dev at openjdk.org Subject: new jextract builds [You don't often get email from maurizio.cimadamore at oracle.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] CAUTION: External email. Be careful when opening links or attachments. Report suspicious emails with the "Report Phishing" button. 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 This e-mail, including attachments, is intended for the person(s) or company(s) named and may contain confidential and/or legally privileged information. Unauthorized disclosure, copying or use of this information may be unlawful and is prohibited. If you are not the intended recipient, please delete this message and notify the sender. All incoming and outgoing e-mail messages are stored in the Swiss Re Electronic Message Repository. If you do not wish the retention of potentially private e-mails by Swiss Re, we strongly advise you not to use the Swiss Re e-mail account for any private, non-business related communications. From jorn.vernee at oracle.com Thu May 30 21:09:40 2024 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Thu, 30 May 2024 23:09:40 +0200 Subject: MacOS In-Reply-To: <0FECE078-27E4-4E17-8D94-493496BABE90@gmail.com> References: <0FECE078-27E4-4E17-8D94-493496BABE90@gmail.com> Message-ID: <913d3c36-e22f-4456-b439-3261bf6f7cf4@oracle.com> Hey Michael, Jextract is not bundled with the JDK anymore. It was moved into a separate repo a few years ago. [1] The jextract executable that you're picking up seems to be coming from an older JDK you have installed? If you want to use jextract, you can download the latest version at: https://jdk.java.net/jextract/ HTH, Jorn [1]: https://github.com/openjdk/jextract On 30/05/2024 20:50, Michael Hall wrote: > 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 at 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 at 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? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri May 31 03:44:13 2024 From: duke at openjdk.org (Ana Maria Mihalceanu) Date: Fri, 31 May 2024 03:44:13 GMT Subject: Integrated: Update macOS version of the OpenGL sample to match the current state of OpenGL/Glut on Mac In-Reply-To: References: Message-ID: On Thu, 23 May 2024 11:36:59 GMT, Ana Maria Mihalceanu wrote: > 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/compile.sh) or [compilesource.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/compilesource.sh) will produce Java code that compiles. > * attempting to run [run.sh](https://github.com/openjdk/jextract/blob/master/samples/opengl/run.sh) 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.(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/master/samples/opengl/compile_flags.txt)](https://github.com/openjdk/jextract/blob/master/samples/opengl/compile_flags.txt) > * 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) This pull request has now been integrated. Changeset: d87ddec9 Author: Ana Committer: Athijegannathan Sundararajan URL: https://git.openjdk.org/jextract/commit/d87ddec91bd5aceaa3882f3bd6d75b18d77e9842 Stats: 10 lines in 4 files changed: 0 ins; 2 del; 8 mod Update macOS version of the OpenGL sample to match the current state of OpenGL/Glut on Mac Reviewed-by: sundar, mcimadamore ------------- PR: https://git.openjdk.org/jextract/pull/245 From nlisker at gmail.com Fri May 31 21:00:01 2024 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 1 Jun 2024 00:00:01 +0300 Subject: Errors on build Message-ID: Hi, In Utils::methodTypeFor(Type.Function type), line 275, I get a compilation error: no suitable method found for methodType(Class ,List>) MethodType.methodType(carrierFor(type.returnType()), type.argumentTypes().stream().map(Utils::carrierFor).toList()); ^ method MethodType.methodType(Class,Class[]) is not applicable (argument mismatch; List> cannot be converted to Class[]) method MethodType.methodType(Class,List>) is not applicable (argument mismatch; List> cannot be converted to List>) method MethodType.methodType(Class,Class,Class...) is not applicable (argument mismatch; List> cannot be converted to Class) method MethodType.methodType(Class,Class) is not applicable (argument mismatch; List> cannot be converted to Class) method MethodType.methodType(Class,MethodType) is not applicable (argument mismatch; List> 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 map(Function). I'm using the master branch commit ID d87ddec91bd5aceaa3882f3bd6d75b18d77e9842 in case this is the wrong branch. Maybe I have some local configuration problem. - Nir -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Fri May 31 21:04:24 2024 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 31 May 2024 22:04:24 +0100 Subject: Errors on build In-Reply-To: References: Message-ID: What JDK are you using to build? Thanks Maurizio On 31/05/2024 22:00, Nir Lisker wrote: > Hi, > > In Utils::methodTypeFor(Type.Function type), line 275, I get a > compilation error: > > ?no suitable method found for methodType(Class > ,List>) > ??MethodType.methodType(carrierFor(type.returnType()), > type.argumentTypes().stream().map(Utils::carrierFor).toList()); > ? ? ? ? ? ? ? ? ? ? ? ? ? ^ > ? ? method MethodType.methodType(Class,Class[]) is not applicable > ? ? ? (argument mismatch; List> cannot be converted to > Class[]) > ? ? method MethodType.methodType(Class,List>) is not > applicable > ? ? ? (argument mismatch; List> cannot be converted to > List>) > ? ? method MethodType.methodType(Class,Class,Class...) is not > applicable > ? ? ? (argument mismatch; List> cannot be converted to > Class) > ? ? method MethodType.methodType(Class,Class) is not applicable > ? ? ? (argument mismatch; List> cannot be converted to > Class) > ? ? method MethodType.methodType(Class,MethodType) is not applicable > ? ? ? (argument mismatch; List> 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 map(Function). > > I'm using the master branch commit > ID?d87ddec91bd5aceaa3882f3bd6d75b18d77e9842 in case this is the wrong > branch. Maybe I have some local configuration problem. > > - Nir -------------- next part -------------- An HTML attachment was scrubbed... URL: