From nbenalla at openjdk.org  Thu Jan  2 19:14:26 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 2 Jan 2025 19:14:26 GMT
Subject: RFR: 7903731: Jextract should support macOS frameworks [v3]
In-Reply-To: <eN2zSInMQq2Mq3jZQMLQMJ932pmJH4ZDzBxrr6Hksgg=.a1c51c51-aaca-4dcd-9c4e-4f419b44e301@github.com>
References: <eN2zSInMQq2Mq3jZQMLQMJ932pmJH4ZDzBxrr6Hksgg=.a1c51c51-aaca-4dcd-9c4e-4f419b44e301@github.com>
Message-ID: <5lkdlfTAzs5AEbVyiw2T2TCVMNf02WuTmTULyh738Vk=.d2553ec3-ab12-47ab-ab98-2c6bf7a3aeef@github.com>

> Read the JBS issue for more detail.
> 
> This patch adds two new mac specific options, to make it easier to use frameworks and remove the need of a `compile_flags.txt` file. An exception is thrown if those options are used from an other platform, the error message is inspired from `jpackage`

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  use consistent spacing

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/268/files
  - new: https://git.openjdk.org/jextract/pull/268/files/aad02674..9ce83f36

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=02
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jextract/pull/268.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/268/head:pull/268

PR: https://git.openjdk.org/jextract/pull/268

From nbenalla at openjdk.org  Thu Jan  2 19:14:26 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 2 Jan 2025 19:14:26 GMT
Subject: RFR: 7903731: Jextract should support macOS frameworks [v2]
In-Reply-To: <PCuaWJoHCm_4FAIMwQz8EPIqzwyZ1ut9UoXrB-dwBkQ=.7fd05c6f-3a80-4f9c-b4c9-da2e5dfbae8b@github.com>
References: <eN2zSInMQq2Mq3jZQMLQMJ932pmJH4ZDzBxrr6Hksgg=.a1c51c51-aaca-4dcd-9c4e-4f419b44e301@github.com>
 <iuoCUIvKBcSZuBE3UdHeMKbhRaDe6y0_5cd7twzpfWY=.64b55bd2-761e-4450-812d-777e04cf79a4@github.com>
 <PCuaWJoHCm_4FAIMwQz8EPIqzwyZ1ut9UoXrB-dwBkQ=.7fd05c6f-3a80-4f9c-b4c9-da2e5dfbae8b@github.com>
Message-ID: <kOKkriQO2PtX8yAnNcHysquenjtEzq7i7x33uPtxwmI=.899c35bb-0dcf-44d3-8fb6-b507cec82c15@github.com>

On Tue, 31 Dec 2024 13:30:02 GMT, Marcono1234 <duke at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typos, rename some methods and bump copyright year to 2025
>
> src/main/resources/org/openjdk/jextract/impl/resources/Messages.properties line 94:
> 
>> 92: --mac-framework-dir <dir>          specify the framework directory                              \n\
>> 93: -f <framework>                    specify framework library. -f libGL is equivalent to         \n\
>> 94: \                                      -l :/System/Library/Frameworks/libGL.framework/libGL         \n
> 
> Wrong / inconsistent indentation?
> Suggestion:
> 
> -f <framework>                     specify framework library. -f libGL is equivalent to         \n\
> \                                   -l :/System/Library/Frameworks/libGL.framework/libGL       \n

Thanks. Fixed the first line in [9ce83f3](https://github.com/openjdk/jextract/pull/268/commits/9ce83f363e50b6e7f3fe5dae1612b929b38a7bd3), the spacing in the second line is intentional.

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1901182955

From nbenalla at openjdk.org  Thu Jan  2 19:18:06 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 2 Jan 2025 19:18:06 GMT
Subject: RFR: 7903735: Remove redundant method in generated code [v2]
In-Reply-To: <-Ae7v0nRNZpg81oM4dHk2PYezOoptiRcSFj1TQEX7PA=.df19261c-a8e5-436e-b183-d867b64fd2fd@github.com>
References: <-Ae7v0nRNZpg81oM4dHk2PYezOoptiRcSFj1TQEX7PA=.df19261c-a8e5-436e-b183-d867b64fd2fd@github.com>
Message-ID: <NWoACNfjw0bEa7nw54pTDXeZ83GQ_3IwTlO6_KX8t8E=.670b2161-0e24-409d-91ae-e7b383e97f1f@github.com>

> Was looking at older issues and saw an opportunity for a refractor.
> I don't see a dependent PR feature for this repo but this is meant to be merged after https://github.com/openjdk/jextract/pull/265

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  (C) 2025

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/266/files
  - new: https://git.openjdk.org/jextract/pull/266/files/aea49d45..e6f28429

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=266&range=01
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=266&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jextract/pull/266.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/266/head:pull/266

PR: https://git.openjdk.org/jextract/pull/266

From nbenalla at openjdk.org  Thu Jan  2 19:24:25 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 2 Jan 2025 19:24:25 GMT
Subject: RFR: 7903922: Update copyright year for jextract in files where it
 was missed [v4]
In-Reply-To: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
References: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
Message-ID: <ja4rwvkkhx4lLxZgoo_LpTckunGqXeQkOxFiP-NMids=.22c7a755-9f19-4555-9f29-0097fac2cf9b@github.com>

> I have sampled a few files to manually check that this works as intended, I got the list of files changed in a certain year by running.
> 
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > 2024file.list
> git log --oneline --since="1/1/2023" --until="31/12/2023" --name-only --pretty=format: | sort -u > 2023file.list
> 
> 
> And then used a script to update the copyright year, I did a random sampling of files to check that it worked as intended.
> 
> A few files had their original copyright year changed because I noticed they were added in 2024 instead.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  (C) 2025

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/267/files
  - new: https://git.openjdk.org/jextract/pull/267/files/918233e1..6ef668f6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=267&range=03
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=267&range=02-03

  Stats: 120 lines in 120 files changed: 0 ins; 0 del; 120 mod
  Patch: https://git.openjdk.org/jextract/pull/267.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/267/head:pull/267

PR: https://git.openjdk.org/jextract/pull/267

From nbenalla at openjdk.org  Thu Jan  2 19:30:21 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 2 Jan 2025 19:30:21 GMT
Subject: RFR: 7903922: Update copyright year for jextract in files where it
 was missed [v5]
In-Reply-To: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
References: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
Message-ID: <MDjAI-46iGV7Q-hZd7MKjzEy_4KqEBRfumw832xoNvU=.4871889a-9234-4e26-971b-acdfb228d8ba@github.com>

> I have sampled a few files to manually check that this works as intended, I got the list of files changed in a certain year by running.
> 
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > 2024file.list
> git log --oneline --since="1/1/2023" --until="31/12/2023" --name-only --pretty=format: | sort -u > 2023file.list
> 
> 
> And then used a script to update the copyright year, I did a random sampling of files to check that it worked as intended.
> 
> A few files had their original copyright year changed because I noticed they were added in 2024 instead.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  Revert "(C) 2025"
  
  This reverts commit 6ef668f69774f2ae1b46f56e97c8ec92301ec9a8.

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/267/files
  - new: https://git.openjdk.org/jextract/pull/267/files/6ef668f6..41b737a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=267&range=04
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=267&range=03-04

  Stats: 120 lines in 120 files changed: 0 ins; 0 del; 120 mod
  Patch: https://git.openjdk.org/jextract/pull/267.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/267/head:pull/267

PR: https://git.openjdk.org/jextract/pull/267

From nbenalla at openjdk.org  Thu Jan  2 21:18:34 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 2 Jan 2025 21:18:34 GMT
Subject: RFR: 7903922: Update copyright year for jextract in files where it
 was missed [v5]
In-Reply-To: <MDjAI-46iGV7Q-hZd7MKjzEy_4KqEBRfumw832xoNvU=.4871889a-9234-4e26-971b-acdfb228d8ba@github.com>
References: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
 <MDjAI-46iGV7Q-hZd7MKjzEy_4KqEBRfumw832xoNvU=.4871889a-9234-4e26-971b-acdfb228d8ba@github.com>
Message-ID: <k3u36Jt4AnBJ1grRyX0QzBNaOM6RMGUcl94wezHRw7o=.dfcc8afb-f6b2-4b42-92a3-90c62224b2c5@github.com>

On Thu, 2 Jan 2025 19:30:21 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> I have sampled a few files to manually check that this works as intended, I got the list of files changed in a certain year by running.
>> 
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > 2024file.list
>> git log --oneline --since="1/1/2023" --until="31/12/2023" --name-only --pretty=format: | sort -u > 2023file.list
>> 
>> 
>> And then used a script to update the copyright year, I did a random sampling of files to check that it worked as intended.
>> 
>> A few files had their original copyright year changed because I noticed they were added in 2024 instead.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "(C) 2025"
>   
>   This reverts commit 6ef668f69774f2ae1b46f56e97c8ec92301ec9a8.

I had to update the copyright header of files modified in this PR to 2025.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/267#issuecomment-2568387346

From nbenalla at openjdk.org  Thu Jan  2 21:18:33 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 2 Jan 2025 21:18:33 GMT
Subject: RFR: 7903922: Update copyright year for jextract in files where it
 was missed [v6]
In-Reply-To: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
References: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
Message-ID: <ts4V9ohumTvC7gUH6ZcbdhO5nEt2b82eMtx0LCr95PU=.e5d2e1a5-598f-4521-9bb6-a0d8dacecae1@github.com>

> I have sampled a few files to manually check that this works as intended, I got the list of files changed in a certain year by running.
> 
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > 2024file.list
> git log --oneline --since="1/1/2023" --until="31/12/2023" --name-only --pretty=format: | sort -u > 2023file.list
> 
> 
> And then used a script to update the copyright year, I did a random sampling of files to check that it worked as intended.
> 
> A few files had their original copyright year changed because I noticed they were added in 2024 instead.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright of files updated in this PR to 2024

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/267/files
  - new: https://git.openjdk.org/jextract/pull/267/files/41b737a0..b334ad01

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=267&range=05
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=267&range=04-05

  Stats: 67 lines in 67 files changed: 0 ins; 0 del; 67 mod
  Patch: https://git.openjdk.org/jextract/pull/267.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/267/head:pull/267

PR: https://git.openjdk.org/jextract/pull/267

From mcimadamore at openjdk.org  Mon Jan  6 11:14:52 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 6 Jan 2025 11:14:52 GMT
Subject: RFR: 7903731: Jextract should support macOS frameworks [v3]
In-Reply-To: <U-Kvno0GNRn7ceR5PSy_YafBVN8ihdSGDdcHJcGg6wU=.7abda893-e626-43b2-ad7d-b1a7e2955469@github.com>
References: <eN2zSInMQq2Mq3jZQMLQMJ932pmJH4ZDzBxrr6Hksgg=.a1c51c51-aaca-4dcd-9c4e-4f419b44e301@github.com>
 <U-Kvno0GNRn7ceR5PSy_YafBVN8ihdSGDdcHJcGg6wU=.7abda893-e626-43b2-ad7d-b1a7e2955469@github.com>
Message-ID: <AqFHe6r4DaJt0dnvI4s46Uvl53Dit-a8NXjw5C2azPg=.9551a31e-cdbf-4dcc-9ace-8cd12b630abd@github.com>

On Mon, 30 Dec 2024 23:55:45 GMT, Marcono1234 <duke at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use consistent spacing
>
> doc/GUIDE.md line 995:
> 
>> 993: | Option                       | Meaning                                                                                                                                                                                                                                 |
>> 994: |:-----------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
>> 995: | `--mac-framework-dir <dir>`  | specify the framework directory dir include files <br/>defaults to the current Mac OS X SDK dir<br/> This removes the need of having a compile_flags.txt with the required `-framework XYZ` options in the folder where jextract is ran |
> 
> Is this "directory dir" intentional?
> Suggestion:
> 
> | `--mac-framework-dir <dir>`  | specify the framework directory include files <br/>defaults to the current Mac OS X SDK dir<br/> This removes the need of having a compile_flags.txt with the required `-framework XYZ` options in the folder where jextract is ran |

I believe I agree with @Marcono1234  - it seems like a typo to me.

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1904026433

From mcimadamore at openjdk.org  Mon Jan  6 11:21:49 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 6 Jan 2025 11:21:49 GMT
Subject: RFR: 7903731: Jextract should support macOS frameworks [v3]
In-Reply-To: <5lkdlfTAzs5AEbVyiw2T2TCVMNf02WuTmTULyh738Vk=.d2553ec3-ab12-47ab-ab98-2c6bf7a3aeef@github.com>
References: <eN2zSInMQq2Mq3jZQMLQMJ932pmJH4ZDzBxrr6Hksgg=.a1c51c51-aaca-4dcd-9c4e-4f419b44e301@github.com>
 <5lkdlfTAzs5AEbVyiw2T2TCVMNf02WuTmTULyh738Vk=.d2553ec3-ab12-47ab-ab98-2c6bf7a3aeef@github.com>
Message-ID: <J_vHbVU6AOE3AWmo3AzYRgyR9z0jrfcFNcmkuC_T2VM=.04c24ee3-4b67-4027-b906-248e49886105@github.com>

On Thu, 2 Jan 2025 19:14:26 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Read the JBS issue for more detail.
>> 
>> This patch adds two new mac specific options, to make it easier to use frameworks and remove the need of a `compile_flags.txt` file. An exception is thrown if those options are used from an other platform, the error message is inspired from `jpackage`
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use consistent spacing

doc/GUIDE.md line 993:

> 991: **macOS platform options (available only when running on macOS):**
> 992: 
> 993: | Option                       | Meaning                                                                                                                                                                                                                                 |

I'd say let's just add these two options to the list above and maybe put some comment (e.g. MacOS only). If we end up with many platform-specific options we can reconsider of course, but I think there's value in having all the options in the same place.

doc/GUIDE.md line 995:

> 993: | Option                       | Meaning                                                                                                                                                                                                                                 |
> 994: |:-----------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
> 995: | `--mac-framework-dir <dir>`  | specify the framework directory dir include files <br/>defaults to the current Mac OS X SDK dir<br/> This removes the need of having a compile_flags.txt with the required `-framework XYZ` options in the folder where jextract is ran |

Maybe we could call this `macos-framework-dir` ?

src/main/resources/org/openjdk/jextract/impl/resources/Messages.properties line 90:

> 88: --version                          print version information and exit                           \n
> 89: 
> 90: jextract.usage.mac=\

Again, not sure it's worth splitting the list of options in two.

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1904029614
PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1904030146
PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1904032364

From mcimadamore at openjdk.org  Mon Jan  6 11:21:49 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 6 Jan 2025 11:21:49 GMT
Subject: RFR: 7903731: Jextract should support macOS frameworks [v3]
In-Reply-To: <J_vHbVU6AOE3AWmo3AzYRgyR9z0jrfcFNcmkuC_T2VM=.04c24ee3-4b67-4027-b906-248e49886105@github.com>
References: <eN2zSInMQq2Mq3jZQMLQMJ932pmJH4ZDzBxrr6Hksgg=.a1c51c51-aaca-4dcd-9c4e-4f419b44e301@github.com>
 <5lkdlfTAzs5AEbVyiw2T2TCVMNf02WuTmTULyh738Vk=.d2553ec3-ab12-47ab-ab98-2c6bf7a3aeef@github.com>
 <J_vHbVU6AOE3AWmo3AzYRgyR9z0jrfcFNcmkuC_T2VM=.04c24ee3-4b67-4027-b906-248e49886105@github.com>
Message-ID: <ctQEO575Frp3vHHn83eYkbviuj43Cf7_ZXGjUQe7TT4=.079f6ed9-709e-4a18-bbf0-a4d53409aaba@github.com>

On Mon, 6 Jan 2025 11:16:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Maybe we could call this `macos-framework-dir` ?

In fact, I wonder if there could be a more general trick here, where platform-specific options have some kind of prefix - so `macos-framework-dir` and `macos-framework`. What do people think?

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1904031351

From mcimadamore at openjdk.org  Mon Jan  6 11:26:48 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 6 Jan 2025 11:26:48 GMT
Subject: RFR: 7903731: Jextract should support macOS frameworks [v3]
In-Reply-To: <5lkdlfTAzs5AEbVyiw2T2TCVMNf02WuTmTULyh738Vk=.d2553ec3-ab12-47ab-ab98-2c6bf7a3aeef@github.com>
References: <eN2zSInMQq2Mq3jZQMLQMJ932pmJH4ZDzBxrr6Hksgg=.a1c51c51-aaca-4dcd-9c4e-4f419b44e301@github.com>
 <5lkdlfTAzs5AEbVyiw2T2TCVMNf02WuTmTULyh738Vk=.d2553ec3-ab12-47ab-ab98-2c6bf7a3aeef@github.com>
Message-ID: <Cmxia5_P73zJzMjW8C5cF4tcUONLP-4P5RSywzAqyzw=.1bdd2e9f-eb9d-47a8-8c64-641a6ff32bf1@github.com>

On Thu, 2 Jan 2025 19:14:26 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Read the JBS issue for more detail.
>> 
>> This patch adds two new mac specific options, to make it easier to use frameworks and remove the need of a `compile_flags.txt` file. An exception is thrown if those options are used from an other platform, the error message is inspired from `jpackage`
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use consistent spacing

src/main/java/org/openjdk/jextract/JextractTool.java line 561:

> 559:                     Library library = Library.parse(lib);
> 560:                     Path libPath = Paths.get(library.libSpec());
> 561:                     if (!useSystemLoadLibrary ||

Do we accept absolute path for macos frameworks? I thought `-f` only works for _names_ ?

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1904036571

From mcimadamore at openjdk.org  Mon Jan  6 11:32:49 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 6 Jan 2025 11:32:49 GMT
Subject: RFR: 7903731: Jextract should support macOS frameworks [v3]
In-Reply-To: <5lkdlfTAzs5AEbVyiw2T2TCVMNf02WuTmTULyh738Vk=.d2553ec3-ab12-47ab-ab98-2c6bf7a3aeef@github.com>
References: <eN2zSInMQq2Mq3jZQMLQMJ932pmJH4ZDzBxrr6Hksgg=.a1c51c51-aaca-4dcd-9c4e-4f419b44e301@github.com>
 <5lkdlfTAzs5AEbVyiw2T2TCVMNf02WuTmTULyh738Vk=.d2553ec3-ab12-47ab-ab98-2c6bf7a3aeef@github.com>
Message-ID: <OT8qDcFWU8wakGuI0h8VaH7HPDRMNAhmNxvwiyFwpQs=.629f44a4-6f7e-4983-b690-9ef4e80fcc17@github.com>

On Thu, 2 Jan 2025 19:14:26 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Read the JBS issue for more detail.
>> 
>> This patch adds two new mac specific options, to make it easier to use frameworks and remove the need of a `compile_flags.txt` file. An exception is thrown if those options are used from an other platform, the error message is inspired from `jpackage`
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use consistent spacing

Great work, I've left some comments for your consideration.

src/main/java/org/openjdk/jextract/JextractTool.java line 553:

> 551:     }
> 552: 
> 553:     private Integer parseLibraries(String optionString, OptionSet optionSet, boolean useSystemLoadLibrary, Options.Builder builder) {

I'd suggest to either use `int` and then `0` for a successful execution, or something like `OptionalInt` if you want to model optionality more explicitly.

src/main/java/org/openjdk/jextract/JextractTool.java line 628:

> 626: 
> 627:     private String formatFrameworkPath(String optionString) {
> 628:         return String.format(":/System/Library/Frameworks/%1$s.framework/%1$s", optionString);

Does this work if a custom framework dir is used? Wouldn't this absolute path point to the wrong place?

-------------

PR Review: https://git.openjdk.org/jextract/pull/268#pullrequestreview-2531944644
PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1904038292
PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1904041573

From mcimadamore at openjdk.org  Mon Jan  6 11:35:48 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 6 Jan 2025 11:35:48 GMT
Subject: RFR: 7903922: Update copyright year for jextract in files where it
 was missed [v6]
In-Reply-To: <ts4V9ohumTvC7gUH6ZcbdhO5nEt2b82eMtx0LCr95PU=.e5d2e1a5-598f-4521-9bb6-a0d8dacecae1@github.com>
References: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
 <ts4V9ohumTvC7gUH6ZcbdhO5nEt2b82eMtx0LCr95PU=.e5d2e1a5-598f-4521-9bb6-a0d8dacecae1@github.com>
Message-ID: <nNkp2BNN4xZrRzagCNC9pt21XBRA_l9dOV1jZyfTzeA=.1f3dbe82-2fca-49e4-a16b-362447fec6ba@github.com>

On Thu, 2 Jan 2025 21:18:33 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> I have sampled a few files to manually check that this works as intended, I got the list of files changed in a certain year by running.
>> 
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > 2024file.list
>> git log --oneline --since="1/1/2023" --until="31/12/2023" --name-only --pretty=format: | sort -u > 2023file.list
>> 
>> 
>> And then used a script to update the copyright year, I did a random sampling of files to check that it worked as intended.
>> 
>> A few files had their original copyright year changed because I noticed they were added in 2024 instead.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright of files updated in this PR to 2024

samples/cblas/TestBlas.java line 2:

> 1: /*
> 2:  * Copyright (c) 2020, 2025, Oracle and/or its affiliates. All rights reserved.

While the change looks ok, I wonder: if a file has only been added in 2020 and never updated afterwards, should we make this change?

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/267#discussion_r1904044904

From jvernee at openjdk.org  Mon Jan  6 11:40:49 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 6 Jan 2025 11:40:49 GMT
Subject: RFR: 7903922: Update copyright year for jextract in files where it
 was missed [v6]
In-Reply-To: <nNkp2BNN4xZrRzagCNC9pt21XBRA_l9dOV1jZyfTzeA=.1f3dbe82-2fca-49e4-a16b-362447fec6ba@github.com>
References: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
 <ts4V9ohumTvC7gUH6ZcbdhO5nEt2b82eMtx0LCr95PU=.e5d2e1a5-598f-4521-9bb6-a0d8dacecae1@github.com>
 <nNkp2BNN4xZrRzagCNC9pt21XBRA_l9dOV1jZyfTzeA=.1f3dbe82-2fca-49e4-a16b-362447fec6ba@github.com>
Message-ID: <Xis28bO3l364KXFSObAFl-mtlY6vb65xb9LUE4agXTc=.706da159-9f26-46ff-a363-d45d0e07c49b@github.com>

On Mon, 6 Jan 2025 11:33:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright of files updated in this PR to 2024
>
> samples/cblas/TestBlas.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2020, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> While the change looks ok, I wonder: if a file has only been added in 2020 and never updated afterwards, should we make this change?

We should only update the copyright year when we actually make changes to those files. We haven't made any changes so far in 2025, so I don't expect to see that year any where.

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/267#discussion_r1904048172

From mcimadamore at openjdk.org  Mon Jan  6 11:44:47 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 6 Jan 2025 11:44:47 GMT
Subject: RFR: 7903923: Derive C_* layouts directly from the Linker
In-Reply-To: <KHQsFnZ53No-QEYKtGPfaBe0UrVUCxaxI6_i8rPVNtY=.ec4577b5-f09e-45db-9790-de312a47460f@github.com>
References: <KHQsFnZ53No-QEYKtGPfaBe0UrVUCxaxI6_i8rPVNtY=.ec4577b5-f09e-45db-9790-de312a47460f@github.com>
Message-ID: <n8h0xWjCGUkjU7yefe5zDh9JBUJX2Yva6RRfUPsd-Lw=.6fe7f20b-5e89-4f1e-a4d2-e779e4bcdba0@github.com>

On Mon, 30 Dec 2024 16:16:41 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Depending on the platform, different `C_*`  correspond to different `JAVA_*` types. We can get those values directly from the linker.
> 
> This patch can allows us to have a common class for different platforms.
> 
> Please review, and thanks in advance!

src/main/java/org/openjdk/jextract/impl/ToplevelBuilder.java line 80:

> 78:             """);
> 79:         if (TypeImpl.IS_WINDOWS) {
> 80:             first.appendIndentedLines("public static final ValueLayout.OfInt C_LONG = (ValueLayout.OfInt) Linker.nativeLinker().canonicalLayouts().get(\"int\");");

The canonical layout for this has name `long`. But the result is a `ValueLayout.OfInt` (because FFM uses `int` to model values of that type on Windows). In other words, the only thing that changes in Windows is the cast that should be to `OfInt`, not to `OfLong`.

src/main/java/org/openjdk/jextract/impl/ToplevelBuilder.java line 81:

> 79:         if (TypeImpl.IS_WINDOWS) {
> 80:             first.appendIndentedLines("public static final ValueLayout.OfInt C_LONG = (ValueLayout.OfInt) Linker.nativeLinker().canonicalLayouts().get(\"int\");");
> 81:             first.appendIndentedLines("public static final ValueLayout.OfDouble C_LONG_DOUBLE = (ValueLayout.OfDouble) Linker.nativeLinker().canonicalLayouts().get(\"double\");");

Here, there's no canonical layout for `long double`. (but what you did retains compatibility with what we had). But I wonder if FFM should add one? @JornVernee , @minborg  ?

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/269#discussion_r1904048922
PR Review Comment: https://git.openjdk.org/jextract/pull/269#discussion_r1904050827

From jvernee at openjdk.org  Mon Jan  6 11:44:48 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 6 Jan 2025 11:44:48 GMT
Subject: RFR: 7903923: Derive C_* layouts directly from the Linker
In-Reply-To: <n8h0xWjCGUkjU7yefe5zDh9JBUJX2Yva6RRfUPsd-Lw=.6fe7f20b-5e89-4f1e-a4d2-e779e4bcdba0@github.com>
References: <KHQsFnZ53No-QEYKtGPfaBe0UrVUCxaxI6_i8rPVNtY=.ec4577b5-f09e-45db-9790-de312a47460f@github.com>
 <n8h0xWjCGUkjU7yefe5zDh9JBUJX2Yva6RRfUPsd-Lw=.6fe7f20b-5e89-4f1e-a4d2-e779e4bcdba0@github.com>
Message-ID: <Ww9j7Ofh48JLMrd2yWUe16Su5-1orm_4dhmwRcfYbpc=.d2e95053-be9c-4ce2-b8ce-6e02f3fe22a5@github.com>

On Mon, 6 Jan 2025 11:39:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Depending on the platform, different `C_*`  correspond to different `JAVA_*` types. We can get those values directly from the linker.
>> 
>> This patch can allows us to have a common class for different platforms.
>> 
>> Please review, and thanks in advance!
>
> src/main/java/org/openjdk/jextract/impl/ToplevelBuilder.java line 81:
> 
>> 79:         if (TypeImpl.IS_WINDOWS) {
>> 80:             first.appendIndentedLines("public static final ValueLayout.OfInt C_LONG = (ValueLayout.OfInt) Linker.nativeLinker().canonicalLayouts().get(\"int\");");
>> 81:             first.appendIndentedLines("public static final ValueLayout.OfDouble C_LONG_DOUBLE = (ValueLayout.OfDouble) Linker.nativeLinker().canonicalLayouts().get(\"double\");");
> 
> Here, there's no canonical layout for `long double`. (but what you did retains compatibility with what we had). But I wonder if FFM should add one? @JornVernee , @minborg  ?

I would be okay with adding `long double` as a canonical layout, just on Windows, if that's what you mean.

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/269#discussion_r1904053085

From jvernee at openjdk.org  Mon Jan  6 11:45:48 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 6 Jan 2025 11:45:48 GMT
Subject: RFR: Update gradle to version 8.11.1 and fix GitHub actions
In-Reply-To: <vWwLzuXE6QTzZaRmRikpqu-c0KGAppQxvfCMjpyxaW4=.c81bc929-4eb4-4a9d-84af-e96946936f25@github.com>
References: <Y7Vc1QeFoSkIY5muQX0Q58h30rttdoFSNFrUtJQu2M0=.cdadeb72-8555-4f03-b1c1-4d2d2e0500cb@github.com>
 <vWwLzuXE6QTzZaRmRikpqu-c0KGAppQxvfCMjpyxaW4=.c81bc929-4eb4-4a9d-84af-e96946936f25@github.com>
Message-ID: <9fadLYLXIzMa_Req8SlkW13P2kuV-0unr14Ex5Er7cM=.b79bf74a-8f6a-464a-b159-e4f5ed03adf9@github.com>

On Mon, 30 Dec 2024 23:47:54 GMT, Marcono1234 <duke at openjdk.org> wrote:

>> Currently the github actions are failing because we depend on versions of the JDK (17 and 22), that are no longer available through the oracle/setup-java github action.
>> 
>> There are 2 barriers to upgrading these JDK version to ones that are supported:
>> 1. The current version of Gradle we are using doesn't run on newer Java versions
>> 2. Due to our use of `--enable-preview` and `--release 22` to compile, we are locked to JDK 22.
>> 
>> This PR updates Gradle to the latest version, which supports running on Java 23. It also drops the `--enable-preview` flag from compilation, which is not actually needed, allowing us to compile using JDK 23 as well. Both these changes then allow us to use JDK 23 to run Gradle, and as a toolchain JDK, in the GitHub actions. Since JDK 23 is available through oracle/setup-java, GitHub actions will work again.
>
> gradle/wrapper/gradle-wrapper.properties line 1:
> 
>> 1: distributionBase=GRADLE_USER_HOME
> 
> Do you want to update `gradle-wrapper.jar` and the `gradlew` scripts as well?
> 
> In that case you will have to run `./gradlew wrapper` a second time locally. See also https://docs.gradle.org/current/userguide/gradle_wrapper.html#sec:upgrading_wrapper.

Yes, that's probably a good idea to do as well. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/264#discussion_r1904054283

From nbenalla at openjdk.org  Mon Jan  6 11:52:04 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 6 Jan 2025 11:52:04 GMT
Subject: RFR: 7903922: Update copyright year for jextract in files where it
 was missed [v6]
In-Reply-To: <Xis28bO3l364KXFSObAFl-mtlY6vb65xb9LUE4agXTc=.706da159-9f26-46ff-a363-d45d0e07c49b@github.com>
References: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
 <ts4V9ohumTvC7gUH6ZcbdhO5nEt2b82eMtx0LCr95PU=.e5d2e1a5-598f-4521-9bb6-a0d8dacecae1@github.com>
 <nNkp2BNN4xZrRzagCNC9pt21XBRA_l9dOV1jZyfTzeA=.1f3dbe82-2fca-49e4-a16b-362447fec6ba@github.com>
 <Xis28bO3l364KXFSObAFl-mtlY6vb65xb9LUE4agXTc=.706da159-9f26-46ff-a363-d45d0e07c49b@github.com>
Message-ID: <lgt5ty9LXg-i6r6f7Lcn04KCl-Hgudt5220ISVguZVs=.78860d1a-9de8-404a-87d6-1aef3c125e7a@github.com>

On Mon, 6 Jan 2025 11:37:03 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> samples/cblas/TestBlas.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2020, 2025, Oracle and/or its affiliates. All rights reserved.
>> 
>> While the change looks ok, I wonder: if a file has only been added in 2020 and never updated afterwards, should we make this change?
>
> We should only update the copyright year when we actually make changes to those files. We haven't made any changes so far in 2025, so I don't expect to see that year any where.

The file was first tracked in git in 2022 and was recently modified in 5a00d7ecb0ea283a4fc5f9fae9a85915028003bc in 2023. It should've had `2020, 2023` but I used the most recent year because that's when I'm making the change.

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/267#discussion_r1904059236

From jvernee at openjdk.org  Mon Jan  6 11:54:02 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 6 Jan 2025 11:54:02 GMT
Subject: RFR: Update gradle to version 8.11.1 and fix GitHub actions [v2]
In-Reply-To: <Y7Vc1QeFoSkIY5muQX0Q58h30rttdoFSNFrUtJQu2M0=.cdadeb72-8555-4f03-b1c1-4d2d2e0500cb@github.com>
References: <Y7Vc1QeFoSkIY5muQX0Q58h30rttdoFSNFrUtJQu2M0=.cdadeb72-8555-4f03-b1c1-4d2d2e0500cb@github.com>
Message-ID: <EtQwNFQ9w2Z_aLRnOz-50rAI4CqImmEtUMRsRm5zOSs=.43a74bd0-a6a5-4c11-b980-bad74527b3c3@github.com>

> Currently the github actions are failing because we depend on versions of the JDK (17 and 22), that are no longer available through the oracle/setup-java github action.
> 
> There are 2 barriers to upgrading these JDK version to ones that are supported:
> 1. The current version of Gradle we are using doesn't run on newer Java versions
> 2. Due to our use of `--enable-preview` and `--release 22` to compile, we are locked to JDK 22.
> 
> This PR updates Gradle to the latest version, which supports running on Java 23. It also drops the `--enable-preview` flag from compilation, which is not actually needed, allowing us to compile using JDK 23 as well. Both these changes then allow us to use JDK 23 to run Gradle, and as a toolchain JDK, in the GitHub actions. Since JDK 23 is available through oracle/setup-java, GitHub actions will work again.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  update wrapper

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/264/files
  - new: https://git.openjdk.org/jextract/pull/264/files/7a433a83..7def72ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=264&range=01
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=264&range=00-01

  Stats: 55 lines in 4 files changed: 26 ins; 1 del; 28 mod
  Patch: https://git.openjdk.org/jextract/pull/264.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/264/head:pull/264

PR: https://git.openjdk.org/jextract/pull/264

From nbenalla at openjdk.org  Mon Jan  6 11:56:48 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 6 Jan 2025 11:56:48 GMT
Subject: RFR: 7903923: Derive C_* layouts directly from the Linker
In-Reply-To: <n8h0xWjCGUkjU7yefe5zDh9JBUJX2Yva6RRfUPsd-Lw=.6fe7f20b-5e89-4f1e-a4d2-e779e4bcdba0@github.com>
References: <KHQsFnZ53No-QEYKtGPfaBe0UrVUCxaxI6_i8rPVNtY=.ec4577b5-f09e-45db-9790-de312a47460f@github.com>
 <n8h0xWjCGUkjU7yefe5zDh9JBUJX2Yva6RRfUPsd-Lw=.6fe7f20b-5e89-4f1e-a4d2-e779e4bcdba0@github.com>
Message-ID: <B8TUDD1Gozek134RWT4pQzOT42yzDXoee39lvB6m-Fk=.a628654b-aef7-4cf6-98c6-edea7b1ef8f3@github.com>

On Mon, 6 Jan 2025 11:37:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Depending on the platform, different `C_*`  correspond to different `JAVA_*` types. We can get those values directly from the linker.
>> 
>> This patch can allows us to have a common class for different platforms.
>> 
>> Please review, and thanks in advance!
>
> src/main/java/org/openjdk/jextract/impl/ToplevelBuilder.java line 80:
> 
>> 78:             """);
>> 79:         if (TypeImpl.IS_WINDOWS) {
>> 80:             first.appendIndentedLines("public static final ValueLayout.OfInt C_LONG = (ValueLayout.OfInt) Linker.nativeLinker().canonicalLayouts().get(\"int\");");
> 
> The canonical layout for this has name `long`. But the result is a `ValueLayout.OfInt` (because FFM uses `int` to model values of that type on Windows). In other words, the only thing that changes in Windows is the cast that should be to `OfInt`, not to `OfLong`.

Thanks for explaining, will fix it.

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/269#discussion_r1904063614

From mcimadamore at openjdk.org  Mon Jan  6 11:57:48 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 6 Jan 2025 11:57:48 GMT
Subject: RFR: 7903922: Update copyright year for jextract in files where it
 was missed [v6]
In-Reply-To: <lgt5ty9LXg-i6r6f7Lcn04KCl-Hgudt5220ISVguZVs=.78860d1a-9de8-404a-87d6-1aef3c125e7a@github.com>
References: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
 <ts4V9ohumTvC7gUH6ZcbdhO5nEt2b82eMtx0LCr95PU=.e5d2e1a5-598f-4521-9bb6-a0d8dacecae1@github.com>
 <nNkp2BNN4xZrRzagCNC9pt21XBRA_l9dOV1jZyfTzeA=.1f3dbe82-2fca-49e4-a16b-362447fec6ba@github.com>
 <Xis28bO3l364KXFSObAFl-mtlY6vb65xb9LUE4agXTc=.706da159-9f26-46ff-a363-d45d0e07c49b@github.com>
 <lgt5ty9LXg-i6r6f7Lcn04KCl-Hgudt5220ISVguZVs=.78860d1a-9de8-404a-87d6-1aef3c125e7a@github.com>
Message-ID: <UBHxEiD8AW9TIorvovlAm7kx3C35vVOSHFteYJuxy8s=.aec5134a-608b-4533-9fbd-a6b7ac041da0@github.com>

On Mon, 6 Jan 2025 11:49:28 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> We should only update the copyright year when we actually make changes to those files. We haven't made any changes so far in 2025, so I don't expect to see that year any where.
>
> The file was first tracked in git in 2022 and was recently modified in 5a00d7ecb0ea283a4fc5f9fae9a85915028003bc in 2023. It should've had `2020, 2023` but I used the most recent year because that's when I'm making the change.

> The file was first tracked in git in 2022 and was recently modified in [5a00d7e](https://github.com/openjdk/jextract/commit/5a00d7ecb0ea283a4fc5f9fae9a85915028003bc) in 2023. It should've had `2020, 2023` but I used the most recent year because that's when I'm making the change.

I see - so in all these case there should be an "interval" in the copyright, and, since we're updating the file now, we're using the current year?

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/267#discussion_r1904064676

From jvernee at openjdk.org  Mon Jan  6 12:02:04 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 6 Jan 2025 12:02:04 GMT
Subject: RFR: Update gradle to version 8.11.1 and fix GitHub actions [v3]
In-Reply-To: <Y7Vc1QeFoSkIY5muQX0Q58h30rttdoFSNFrUtJQu2M0=.cdadeb72-8555-4f03-b1c1-4d2d2e0500cb@github.com>
References: <Y7Vc1QeFoSkIY5muQX0Q58h30rttdoFSNFrUtJQu2M0=.cdadeb72-8555-4f03-b1c1-4d2d2e0500cb@github.com>
Message-ID: <q9mjpxalb16fRRDSaVZ0dBluda3tj6YKMTcGVyStGHg=.6ff5a5d9-1a62-4a5e-b76b-3618ea437a2f@github.com>

> Currently the github actions are failing because we depend on versions of the JDK (17 and 22), that are no longer available through the oracle/setup-java github action.
> 
> There are 2 barriers to upgrading these JDK version to ones that are supported:
> 1. The current version of Gradle we are using doesn't run on newer Java versions
> 2. Due to our use of `--enable-preview` and `--release 22` to compile, we are locked to JDK 22.
> 
> This PR updates Gradle to the latest version, which supports running on Java 23. It also drops the `--enable-preview` flag from compilation, which is not actually needed, allowing us to compile using JDK 23 as well. Both these changes then allow us to use JDK 23 to run Gradle, and as a toolchain JDK, in the GitHub actions. Since JDK 23 is available through oracle/setup-java, GitHub actions will work again.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Add gradle wrapper validation step

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/264/files
  - new: https://git.openjdk.org/jextract/pull/264/files/7def72ae..a4ff0095

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=264&range=02
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=264&range=01-02

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jextract/pull/264.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/264/head:pull/264

PR: https://git.openjdk.org/jextract/pull/264

From nbenalla at openjdk.org  Mon Jan  6 12:06:54 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 6 Jan 2025 12:06:54 GMT
Subject: RFR: 7903731: Jextract should support macOS frameworks [v3]
In-Reply-To: <J_vHbVU6AOE3AWmo3AzYRgyR9z0jrfcFNcmkuC_T2VM=.04c24ee3-4b67-4027-b906-248e49886105@github.com>
References: <eN2zSInMQq2Mq3jZQMLQMJ932pmJH4ZDzBxrr6Hksgg=.a1c51c51-aaca-4dcd-9c4e-4f419b44e301@github.com>
 <5lkdlfTAzs5AEbVyiw2T2TCVMNf02WuTmTULyh738Vk=.d2553ec3-ab12-47ab-ab98-2c6bf7a3aeef@github.com>
 <J_vHbVU6AOE3AWmo3AzYRgyR9z0jrfcFNcmkuC_T2VM=.04c24ee3-4b67-4027-b906-248e49886105@github.com>
Message-ID: <f4nvmKytopjXzOBdwhfZCJ3MqdYBRNMy5eb0TGTp-9I=.0ef47ace-114d-48b7-a64b-f58e795dce61@github.com>

On Mon, 6 Jan 2025 11:19:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use consistent spacing
>
> src/main/resources/org/openjdk/jextract/impl/resources/Messages.properties line 90:
> 
>> 88: --version                          print version information and exit                           \n
>> 89: 
>> 90: jextract.usage.mac=\
> 
> Again, not sure it's worth splitting the list of options in two.

Sure, I did this so that I can show these options only if you're running MacOs

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1904072007

From nbenalla at openjdk.org  Mon Jan  6 12:47:00 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 6 Jan 2025 12:47:00 GMT
Subject: RFR: 7903731: Jextract should support macOS frameworks [v3]
In-Reply-To: <Cmxia5_P73zJzMjW8C5cF4tcUONLP-4P5RSywzAqyzw=.1bdd2e9f-eb9d-47a8-8c64-641a6ff32bf1@github.com>
References: <eN2zSInMQq2Mq3jZQMLQMJ932pmJH4ZDzBxrr6Hksgg=.a1c51c51-aaca-4dcd-9c4e-4f419b44e301@github.com>
 <5lkdlfTAzs5AEbVyiw2T2TCVMNf02WuTmTULyh738Vk=.d2553ec3-ab12-47ab-ab98-2c6bf7a3aeef@github.com>
 <Cmxia5_P73zJzMjW8C5cF4tcUONLP-4P5RSywzAqyzw=.1bdd2e9f-eb9d-47a8-8c64-641a6ff32bf1@github.com>
Message-ID: <vNwotvuiRML7M7MMkJ8gsLSnWEKKtjD6rUQ3fwRf-IM=.742439e7-8f11-47f4-aa56-dce324113c57@github.com>

On Mon, 6 Jan 2025 11:24:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use consistent spacing
>
> src/main/java/org/openjdk/jextract/JextractTool.java line 561:
> 
>> 559:                     Library library = Library.parse(lib);
>> 560:                     Path libPath = Paths.get(library.libSpec());
>> 561:                     if (!useSystemLoadLibrary ||
> 
> Do we accept absolute path for macos frameworks? I thought `-f` only works for _names_ ?

I did this to try to reuse some code.
`-f` is only intended to work with names, otherwise an error should be reported but I will double check.

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1904108080

From jvernee at openjdk.org  Mon Jan  6 12:47:32 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 6 Jan 2025 12:47:32 GMT
Subject: RFR: Update gradle to version 8.11.1 and fix GitHub actions [v4]
In-Reply-To: <Y7Vc1QeFoSkIY5muQX0Q58h30rttdoFSNFrUtJQu2M0=.cdadeb72-8555-4f03-b1c1-4d2d2e0500cb@github.com>
References: <Y7Vc1QeFoSkIY5muQX0Q58h30rttdoFSNFrUtJQu2M0=.cdadeb72-8555-4f03-b1c1-4d2d2e0500cb@github.com>
Message-ID: <WijKy4galf3IM1kPxxr7x7qfrUUoDW7bL6O5g_5I204=.58839f3f-2d04-438d-b629-7f6ce76d08aa@github.com>

> Currently the github actions are failing because we depend on versions of the JDK (17 and 22), that are no longer available through the oracle/setup-java github action.
> 
> There are 2 barriers to upgrading these JDK version to ones that are supported:
> 1. The current version of Gradle we are using doesn't run on newer Java versions
> 2. Due to our use of `--enable-preview` and `--release 22` to compile, we are locked to JDK 22.
> 
> This PR updates Gradle to the latest version, which supports running on Java 23. It also drops the `--enable-preview` flag from compilation, which is not actually needed, allowing us to compile using JDK 23 as well. Both these changes then allow us to use JDK 23 to run Gradle, and as a toolchain JDK, in the GitHub actions. Since JDK 23 is available through oracle/setup-java, GitHub actions will work again.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Separate validate job, so it doesn't get repeated

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/264/files
  - new: https://git.openjdk.org/jextract/pull/264/files/a4ff0095..2b77dc78

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=264&range=03
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=264&range=02-03

  Stats: 12 lines in 1 file changed: 9 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jextract/pull/264.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/264/head:pull/264

PR: https://git.openjdk.org/jextract/pull/264

From jvernee at openjdk.org  Mon Jan  6 12:47:34 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 6 Jan 2025 12:47:34 GMT
Subject: RFR: Update gradle to version 8.11.1 and fix GitHub actions [v3]
In-Reply-To: <q9mjpxalb16fRRDSaVZ0dBluda3tj6YKMTcGVyStGHg=.6ff5a5d9-1a62-4a5e-b76b-3618ea437a2f@github.com>
References: <Y7Vc1QeFoSkIY5muQX0Q58h30rttdoFSNFrUtJQu2M0=.cdadeb72-8555-4f03-b1c1-4d2d2e0500cb@github.com>
 <q9mjpxalb16fRRDSaVZ0dBluda3tj6YKMTcGVyStGHg=.6ff5a5d9-1a62-4a5e-b76b-3618ea437a2f@github.com>
Message-ID: <LdLBxcBiN8oQytaqX18FPROzsvP9Y2Cv6mgznxuTUBs=.d17a34df-8429-4237-a5e3-c8962133128d@github.com>

On Mon, 6 Jan 2025 12:02:04 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Currently the github actions are failing because we depend on versions of the JDK (17 and 22), that are no longer available through the oracle/setup-java github action.
>> 
>> There are 2 barriers to upgrading these JDK version to ones that are supported:
>> 1. The current version of Gradle we are using doesn't run on newer Java versions
>> 2. Due to our use of `--enable-preview` and `--release 22` to compile, we are locked to JDK 22.
>> 
>> This PR updates Gradle to the latest version, which supports running on Java 23. It also drops the `--enable-preview` flag from compilation, which is not actually needed, allowing us to compile using JDK 23 as well. Both these changes then allow us to use JDK 23 to run Gradle, and as a toolchain JDK, in the GitHub actions. Since JDK 23 is available through oracle/setup-java, GitHub actions will work again.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add gradle wrapper validation step

I've updated the wrapper as well, and added wrapper validation as a step to github actions, so we check that the .jar file has the right checksum.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/264#issuecomment-2573034916

From nbenalla at openjdk.org  Mon Jan  6 12:51:48 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 6 Jan 2025 12:51:48 GMT
Subject: RFR: 7903922: Update copyright year for jextract in files where it
 was missed [v6]
In-Reply-To: <UBHxEiD8AW9TIorvovlAm7kx3C35vVOSHFteYJuxy8s=.aec5134a-608b-4533-9fbd-a6b7ac041da0@github.com>
References: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
 <ts4V9ohumTvC7gUH6ZcbdhO5nEt2b82eMtx0LCr95PU=.e5d2e1a5-598f-4521-9bb6-a0d8dacecae1@github.com>
 <nNkp2BNN4xZrRzagCNC9pt21XBRA_l9dOV1jZyfTzeA=.1f3dbe82-2fca-49e4-a16b-362447fec6ba@github.com>
 <Xis28bO3l364KXFSObAFl-mtlY6vb65xb9LUE4agXTc=.706da159-9f26-46ff-a363-d45d0e07c49b@github.com>
 <lgt5ty9LXg-i6r6f7Lcn04KCl-Hgudt5220ISVguZVs=.78860d1a-9de8-404a-87d6-1aef3c125e7a@github.com>
 <UBHxEiD8AW9TIorvovlAm7kx3C35vVOSHFteYJuxy8s=.aec5134a-608b-4533-9fbd-a6b7ac041da0@github.com>
Message-ID: <u97bNJ6rHKFTziQ2PZ749c5or2mIRXE0x8P2Bm6EhLM=.dbf17eca-01f6-4925-b8d3-779b3432a7ef@github.com>

On Mon, 6 Jan 2025 11:55:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The file was first tracked in git in 2022 and was recently modified in 5a00d7ecb0ea283a4fc5f9fae9a85915028003bc in 2023. It should've had `2020, 2023` but I used the most recent year because that's when I'm making the change.
>
>> The file was first tracked in git in 2022 and was recently modified in [5a00d7e](https://github.com/openjdk/jextract/commit/5a00d7ecb0ea283a4fc5f9fae9a85915028003bc) in 2023. It should've had `2020, 2023` but I used the most recent year because that's when I'm making the change.
> 
> I see - so in all these case there should be an "interval" in the copyright, and, since we're updating the file now, we're using the current year?

Yes that's exactly what I did. 

The only exception are the files listed before. They were first added in 357e649157c78067fed03491e945683ce7c1680b. I noticed the first year in the interval should have been "2024" instead of "2023" so I changed it. What do you think?


test/jtreg/generator/nestedInsideAnon/TestNestedInsideAnon.java
test/jtreg/generator/nestedInsideAnon/nestedInsideAnon.h
test/jtreg/generator/nestedTypes/TestNestedTypesNames.java
test/jtreg/generator/nestedTypes/TestNestedTypesUnsupported.java
test/jtreg/generator/nestedTypes/nested_types_names.h
test/jtreg/generator/nestedTypes/nested_types_unsupported.h
test/jtreg/generator/outOfOrder/TestOutOfOrderStruct.java
test/jtreg/generator/outOfOrder/TestOutOfOrderTypedef.java
test/jtreg/generator/outOfOrder/out_of_order_struct.h
test/jtreg/generator/outOfOrder/out_of_order_typedef.h

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/267#discussion_r1904113594

From jvernee at openjdk.org  Mon Jan  6 13:00:21 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 6 Jan 2025 13:00:21 GMT
Subject: RFR: Update gradle to version 8.11.1 and fix GitHub actions [v5]
In-Reply-To: <Y7Vc1QeFoSkIY5muQX0Q58h30rttdoFSNFrUtJQu2M0=.cdadeb72-8555-4f03-b1c1-4d2d2e0500cb@github.com>
References: <Y7Vc1QeFoSkIY5muQX0Q58h30rttdoFSNFrUtJQu2M0=.cdadeb72-8555-4f03-b1c1-4d2d2e0500cb@github.com>
Message-ID: <-NGpBS22VQTitzbJUwIF0Z51aw6tCeEOyZz8OAG29v8=.5729fd40-048b-43e5-b9fd-241d3f267534@github.com>

> Currently the github actions are failing because we depend on versions of the JDK (17 and 22), that are no longer available through the oracle/setup-java github action.
> 
> There are 2 barriers to upgrading these JDK version to ones that are supported:
> 1. The current version of Gradle we are using doesn't run on newer Java versions
> 2. Due to our use of `--enable-preview` and `--release 22` to compile, we are locked to JDK 22.
> 
> This PR updates Gradle to the latest version, which supports running on Java 23. It also drops the `--enable-preview` flag from compilation, which is not actually needed, allowing us to compile using JDK 23 as well. Both these changes then allow us to use JDK 23 to run Gradle, and as a toolchain JDK, in the GitHub actions. Since JDK 23 is available through oracle/setup-java, GitHub actions will work again.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Remove validate job name to match others

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/264/files
  - new: https://git.openjdk.org/jextract/pull/264/files/2b77dc78..d684f81f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=264&range=04
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=264&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jextract/pull/264.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/264/head:pull/264

PR: https://git.openjdk.org/jextract/pull/264

From mcimadamore at openjdk.org  Mon Jan  6 13:10:48 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 6 Jan 2025 13:10:48 GMT
Subject: RFR: Update gradle to version 8.11.1 and fix GitHub actions [v5]
In-Reply-To: <-NGpBS22VQTitzbJUwIF0Z51aw6tCeEOyZz8OAG29v8=.5729fd40-048b-43e5-b9fd-241d3f267534@github.com>
References: <Y7Vc1QeFoSkIY5muQX0Q58h30rttdoFSNFrUtJQu2M0=.cdadeb72-8555-4f03-b1c1-4d2d2e0500cb@github.com>
 <-NGpBS22VQTitzbJUwIF0Z51aw6tCeEOyZz8OAG29v8=.5729fd40-048b-43e5-b9fd-241d3f267534@github.com>
Message-ID: <thvecQWA8l5IiGyGRr9trZdL0nKj2BGxaElWHqfebgc=.cf0b326e-18f3-403a-bb55-946b36712c87@github.com>

On Mon, 6 Jan 2025 13:00:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Currently the github actions are failing because we depend on versions of the JDK (17 and 22), that are no longer available through the oracle/setup-java github action.
>> 
>> There are 2 barriers to upgrading these JDK version to ones that are supported:
>> 1. The current version of Gradle we are using doesn't run on newer Java versions
>> 2. Due to our use of `--enable-preview` and `--release 22` to compile, we are locked to JDK 22.
>> 
>> This PR updates Gradle to the latest version, which supports running on Java 23. It also drops the `--enable-preview` flag from compilation, which is not actually needed, allowing us to compile using JDK 23 as well. Both these changes then allow us to use JDK 23 to run Gradle, and as a toolchain JDK, in the GitHub actions. Since JDK 23 is available through oracle/setup-java, GitHub actions will work again.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove validate job name to match others

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jextract/pull/264#pullrequestreview-2532105947

From mcimadamore at openjdk.org  Mon Jan  6 13:11:49 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 6 Jan 2025 13:11:49 GMT
Subject: RFR: 7903922: Update copyright year for jextract in files where it
 was missed [v6]
In-Reply-To: <ts4V9ohumTvC7gUH6ZcbdhO5nEt2b82eMtx0LCr95PU=.e5d2e1a5-598f-4521-9bb6-a0d8dacecae1@github.com>
References: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
 <ts4V9ohumTvC7gUH6ZcbdhO5nEt2b82eMtx0LCr95PU=.e5d2e1a5-598f-4521-9bb6-a0d8dacecae1@github.com>
Message-ID: <4olwwdwpMXMREOPMcuchctfBKEuBK9OBEkj_5Qfjo9Q=.e5bec3d3-b4f2-466a-addd-5cf13d22372a@github.com>

On Thu, 2 Jan 2025 21:18:33 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> I have sampled a few files to manually check that this works as intended, I got the list of files changed in a certain year by running.
>> 
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > 2024file.list
>> git log --oneline --since="1/1/2023" --until="31/12/2023" --name-only --pretty=format: | sort -u > 2023file.list
>> 
>> 
>> And then used a script to update the copyright year, I did a random sampling of files to check that it worked as intended.
>> 
>> A few files had their original copyright year changed because I noticed they were added in 2024 instead.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright of files updated in this PR to 2024

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jextract/pull/267#pullrequestreview-2532107362

From mcimadamore at openjdk.org  Mon Jan  6 13:11:49 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 6 Jan 2025 13:11:49 GMT
Subject: RFR: 7903922: Update copyright year for jextract in files where it
 was missed [v6]
In-Reply-To: <u97bNJ6rHKFTziQ2PZ749c5or2mIRXE0x8P2Bm6EhLM=.dbf17eca-01f6-4925-b8d3-779b3432a7ef@github.com>
References: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
 <ts4V9ohumTvC7gUH6ZcbdhO5nEt2b82eMtx0LCr95PU=.e5d2e1a5-598f-4521-9bb6-a0d8dacecae1@github.com>
 <nNkp2BNN4xZrRzagCNC9pt21XBRA_l9dOV1jZyfTzeA=.1f3dbe82-2fca-49e4-a16b-362447fec6ba@github.com>
 <Xis28bO3l364KXFSObAFl-mtlY6vb65xb9LUE4agXTc=.706da159-9f26-46ff-a363-d45d0e07c49b@github.com>
 <lgt5ty9LXg-i6r6f7Lcn04KCl-Hgudt5220ISVguZVs=.78860d1a-9de8-404a-87d6-1aef3c125e7a@github.com>
 <UBHxEiD8AW9TIorvovlAm7kx3C35vVOSHFteYJuxy8s=.aec5134a-608b-4533-9fbd-a6b7ac041da0@github.com>
 <u97bNJ6rHKFTziQ2PZ749c5or2mIRXE0x8P2Bm6EhLM=.dbf17eca-01f6-4925-b8d3-779b3432a7ef@github.com>
Message-ID: <cvQRZFaPPOMnZAb3h6pel6hw3srv-jYgYDLfwwXnCfk=.0d6978c8-46f3-4e2a-96cb-71d6717776eb@github.com>

On Mon, 6 Jan 2025 12:49:18 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>>> The file was first tracked in git in 2022 and was recently modified in [5a00d7e](https://github.com/openjdk/jextract/commit/5a00d7ecb0ea283a4fc5f9fae9a85915028003bc) in 2023. It should've had `2020, 2023` but I used the most recent year because that's when I'm making the change.
>> 
>> I see - so in all these case there should be an "interval" in the copyright, and, since we're updating the file now, we're using the current year?
>
> Yes that's exactly what I did. 
> 
> The only exception are the files listed before. They were first added in 357e649157c78067fed03491e945683ce7c1680b. I noticed the first year in the interval should have been "2024" instead of "2023" so I changed it. What do you think?
> 
> 
> test/jtreg/generator/nestedInsideAnon/TestNestedInsideAnon.java
> test/jtreg/generator/nestedInsideAnon/nestedInsideAnon.h
> test/jtreg/generator/nestedTypes/TestNestedTypesNames.java
> test/jtreg/generator/nestedTypes/TestNestedTypesUnsupported.java
> test/jtreg/generator/nestedTypes/nested_types_names.h
> test/jtreg/generator/nestedTypes/nested_types_unsupported.h
> test/jtreg/generator/outOfOrder/TestOutOfOrderStruct.java
> test/jtreg/generator/outOfOrder/TestOutOfOrderTypedef.java
> test/jtreg/generator/outOfOrder/out_of_order_struct.h
> test/jtreg/generator/outOfOrder/out_of_order_typedef.h

I think your changes seem sensible.

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/267#discussion_r1904131478

From jvernee at openjdk.org  Mon Jan  6 13:25:50 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 6 Jan 2025 13:25:50 GMT
Subject: Integrated: Update gradle to version 8.11.1 and fix GitHub actions
In-Reply-To: <Y7Vc1QeFoSkIY5muQX0Q58h30rttdoFSNFrUtJQu2M0=.cdadeb72-8555-4f03-b1c1-4d2d2e0500cb@github.com>
References: <Y7Vc1QeFoSkIY5muQX0Q58h30rttdoFSNFrUtJQu2M0=.cdadeb72-8555-4f03-b1c1-4d2d2e0500cb@github.com>
Message-ID: <c6SYeVE9ee08MAB6VgsSdD7ah2hkbciBRAvjBxCu5Ug=.d312e237-ee46-4ae8-af59-e8c8cc011ac4@github.com>

On Tue, 17 Dec 2024 13:35:13 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Currently the github actions are failing because we depend on versions of the JDK (17 and 22), that are no longer available through the oracle/setup-java github action.
> 
> There are 2 barriers to upgrading these JDK version to ones that are supported:
> 1. The current version of Gradle we are using doesn't run on newer Java versions
> 2. Due to our use of `--enable-preview` and `--release 22` to compile, we are locked to JDK 22.
> 
> This PR updates Gradle to the latest version, which supports running on Java 23. It also drops the `--enable-preview` flag from compilation, which is not actually needed, allowing us to compile using JDK 23 as well. Both these changes then allow us to use JDK 23 to run Gradle, and as a toolchain JDK, in the GitHub actions. Since JDK 23 is available through oracle/setup-java, GitHub actions will work again.

This pull request has now been integrated.

Changeset: 360bdc9c
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/360bdc9cec421ebd7e2830a84cd5f6f4e22358c3
Stats:     77 lines in 7 files changed: 37 ins; 4 del; 36 mod

Update gradle to version 8.11.1 and fix GitHub actions

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jextract/pull/264

From jvernee at openjdk.org  Mon Jan  6 13:32:48 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 6 Jan 2025 13:32:48 GMT
Subject: RFR: 7903922: Update copyright year for jextract in files where it
 was missed [v6]
In-Reply-To: <ts4V9ohumTvC7gUH6ZcbdhO5nEt2b82eMtx0LCr95PU=.e5d2e1a5-598f-4521-9bb6-a0d8dacecae1@github.com>
References: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
 <ts4V9ohumTvC7gUH6ZcbdhO5nEt2b82eMtx0LCr95PU=.e5d2e1a5-598f-4521-9bb6-a0d8dacecae1@github.com>
Message-ID: <W2rydDvHObDqCTFfNdTmTsSbaSoHzZGnomdYa7I5C8g=.0510804f-6549-40fa-ac98-4aa688bb84fd@github.com>

On Thu, 2 Jan 2025 21:18:33 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> I have sampled a few files to manually check that this works as intended, I got the list of files changed in a certain year by running.
>> 
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > 2024file.list
>> git log --oneline --since="1/1/2023" --until="31/12/2023" --name-only --pretty=format: | sort -u > 2023file.list
>> 
>> 
>> And then used a script to update the copyright year, I did a random sampling of files to check that it worked as intended.
>> 
>> A few files had their original copyright year changed because I noticed they were added in 2024 instead.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright of files updated in this PR to 2024

I'm not sure what the right thing to do here is. Even a trivial change requires a copyright year bump, but I'm not sure whether that applies to the copyright header itself. It seems paradoxical. We could set the year for every file in the repo to 2025, just because that year update would require setting the year to 2025?

-------------

PR Comment: https://git.openjdk.org/jextract/pull/267#issuecomment-2573115601

From mcimadamore at openjdk.org  Mon Jan  6 14:50:53 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 6 Jan 2025 14:50:53 GMT
Subject: RFR: 7903731: Jextract should support macOS frameworks [v3]
In-Reply-To: <5lkdlfTAzs5AEbVyiw2T2TCVMNf02WuTmTULyh738Vk=.d2553ec3-ab12-47ab-ab98-2c6bf7a3aeef@github.com>
References: <eN2zSInMQq2Mq3jZQMLQMJ932pmJH4ZDzBxrr6Hksgg=.a1c51c51-aaca-4dcd-9c4e-4f419b44e301@github.com>
 <5lkdlfTAzs5AEbVyiw2T2TCVMNf02WuTmTULyh738Vk=.d2553ec3-ab12-47ab-ab98-2c6bf7a3aeef@github.com>
Message-ID: <AcIHhqsqUSpWTKVAGX3DC3UAR0vNr8wif27u4M-GPVQ=.341db869-79eb-4a0f-ad5b-028cd35c88af@github.com>

On Thu, 2 Jan 2025 19:14:26 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Read the JBS issue for more detail.
>> 
>> This patch adds two new mac specific options, to make it easier to use frameworks and remove the need of a `compile_flags.txt` file. An exception is thrown if those options are used from an other platform, the error message is inspired from `jpackage`
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use consistent spacing

We should make sure that users can specify both `-f` and `-l` and they are _both_ reflected in the generated sources (e.g. in case users would like to generate a single set of sources that work across multiple platforms).

-------------

PR Comment: https://git.openjdk.org/jextract/pull/268#issuecomment-2573266731

From jvernee at openjdk.org  Mon Jan  6 15:28:51 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 6 Jan 2025 15:28:51 GMT
Subject: RFR: 7903731: Jextract should support macOS frameworks [v3]
In-Reply-To: <5lkdlfTAzs5AEbVyiw2T2TCVMNf02WuTmTULyh738Vk=.d2553ec3-ab12-47ab-ab98-2c6bf7a3aeef@github.com>
References: <eN2zSInMQq2Mq3jZQMLQMJ932pmJH4ZDzBxrr6Hksgg=.a1c51c51-aaca-4dcd-9c4e-4f419b44e301@github.com>
 <5lkdlfTAzs5AEbVyiw2T2TCVMNf02WuTmTULyh738Vk=.d2553ec3-ab12-47ab-ab98-2c6bf7a3aeef@github.com>
Message-ID: <dSQYlAQ_3UiXxeLsE7kOvg7DkVbQxWVelwiHo4MI4-c=.938ec48f-6d8c-4bea-83ee-419ef27fb545@github.com>

On Thu, 2 Jan 2025 19:14:26 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Read the JBS issue for more detail.
>> 
>> This patch adds two new mac specific options, to make it easier to use frameworks and remove the need of a `compile_flags.txt` file. An exception is thrown if those options are used from an other platform, the error message is inspired from `jpackage`
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use consistent spacing

src/main/java/org/openjdk/jextract/JextractTool.java line 393:

> 391: 
> 392:         parser.addPlatformOption("--mac-framework-dir");
> 393:         parser.addPlatformOption("-f");

Is `addPlatformOption` just for showing a different error message?

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1904291712

From nbenalla at openjdk.org  Mon Jan  6 15:34:59 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 6 Jan 2025 15:34:59 GMT
Subject: RFR: 7903731: Jextract should support macOS frameworks [v3]
In-Reply-To: <dSQYlAQ_3UiXxeLsE7kOvg7DkVbQxWVelwiHo4MI4-c=.938ec48f-6d8c-4bea-83ee-419ef27fb545@github.com>
References: <eN2zSInMQq2Mq3jZQMLQMJ932pmJH4ZDzBxrr6Hksgg=.a1c51c51-aaca-4dcd-9c4e-4f419b44e301@github.com>
 <5lkdlfTAzs5AEbVyiw2T2TCVMNf02WuTmTULyh738Vk=.d2553ec3-ab12-47ab-ab98-2c6bf7a3aeef@github.com>
 <dSQYlAQ_3UiXxeLsE7kOvg7DkVbQxWVelwiHo4MI4-c=.938ec48f-6d8c-4bea-83ee-419ef27fb545@github.com>
Message-ID: <LuzaPylfHGf6jGgjQnaT8Xm2reigLLHGrPZLW8XdYyo=.435e68f5-e784-4d72-80a0-ce9cc9402875@github.com>

On Mon, 6 Jan 2025 15:26:33 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use consistent spacing
>
> src/main/java/org/openjdk/jextract/JextractTool.java line 393:
> 
>> 391: 
>> 392:         parser.addPlatformOption("--mac-framework-dir");
>> 393:         parser.addPlatformOption("-f");
> 
> Is `addPlatformOption` just for showing a different error message?

Yes, I wanted to have a similar error message to that of `jpackage`.

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1904297941

From nbenalla at openjdk.org  Mon Jan  6 15:59:25 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 6 Jan 2025 15:59:25 GMT
Subject: RFR: 7903923: Derive C_* layouts directly from the Linker [v2]
In-Reply-To: <KHQsFnZ53No-QEYKtGPfaBe0UrVUCxaxI6_i8rPVNtY=.ec4577b5-f09e-45db-9790-de312a47460f@github.com>
References: <KHQsFnZ53No-QEYKtGPfaBe0UrVUCxaxI6_i8rPVNtY=.ec4577b5-f09e-45db-9790-de312a47460f@github.com>
Message-ID: <8liMbJmMnocnzmGaPHA860zzQgQD8QfoYZwAtvyJnxc=.ed78a457-38eb-4001-9d89-702aa7dcd855@github.com>

> Depending on the platform, different `C_*`  correspond to different `JAVA_*` types. We can get those values directly from the linker.
> 
> This patch can allows us to have a common class for different platforms.
> 
> Please review, and thanks in advance!

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  Fix the C_LONG layout in windows

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/269/files
  - new: https://git.openjdk.org/jextract/pull/269/files/4e60dfe2..ed192bbf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=269&range=01
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=269&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jextract/pull/269.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/269/head:pull/269

PR: https://git.openjdk.org/jextract/pull/269

From nbenalla at openjdk.org  Mon Jan  6 16:08:54 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 6 Jan 2025 16:08:54 GMT
Subject: RFR: 7903923: Derive C_* layouts directly from the Linker [v2]
In-Reply-To: <8liMbJmMnocnzmGaPHA860zzQgQD8QfoYZwAtvyJnxc=.ed78a457-38eb-4001-9d89-702aa7dcd855@github.com>
References: <KHQsFnZ53No-QEYKtGPfaBe0UrVUCxaxI6_i8rPVNtY=.ec4577b5-f09e-45db-9790-de312a47460f@github.com>
 <8liMbJmMnocnzmGaPHA860zzQgQD8QfoYZwAtvyJnxc=.ed78a457-38eb-4001-9d89-702aa7dcd855@github.com>
Message-ID: <WGb4Uh2jdO9f8s5HR8ljrJ9fNo5Hb5eg1rHXWSj0Tjg=.e98cc683-1172-43be-8595-1cd4a5bba678@github.com>

On Mon, 6 Jan 2025 15:59:25 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Depending on the platform, different `C_*`  correspond to different `JAVA_*` types. We can get those values directly from the linker.
>> 
>> This patch can allows us to have a common class for different platforms.
>> 
>> Please review, and thanks in advance!
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the C_LONG layout in windows

I'm seeing multiple failures on windows (and only on windows), will need to investigate.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/269#issuecomment-2573421586

From nbenalla at openjdk.org  Mon Jan  6 16:21:59 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 6 Jan 2025 16:21:59 GMT
Subject: RFR: 7903917: Changes needed for jdk23-based makefile build [v3]
In-Reply-To: <N2zZFH5K0mJvIHrnsQO1rdGoG-V9UWijFJ0cfYrjWug=.e3627731-c6ef-4ff8-9d4c-826623abe0d5@github.com>
References: <N2zZFH5K0mJvIHrnsQO1rdGoG-V9UWijFJ0cfYrjWug=.e3627731-c6ef-4ff8-9d4c-826623abe0d5@github.com>
Message-ID: <9cdDJAeZqTSEvKxM0ZVJQF-oJsXGAbqlPuDby9fceGw=.f28bfad4-1216-448d-bb63-69dc2fa15cad@github.com>

> Changes necessary to bump the supported version to JDK 23.
> Passes tier 1.
> 
> Note: This PR will not be integrated before https://github.com/openjdk/jextract/pull/264 as the removal of `--enable-preview` is needed.

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge remote-tracking branch 'upstream/master' into CODETOOLS-7903917
   
   # Conflicts:
   #	make/Build.gmk
 - remove --release flag
 - CODETOOLS-7903917

-------------

Changes: https://git.openjdk.org/jextract/pull/265/files
  Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=265&range=02
  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jextract/pull/265.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/265/head:pull/265

PR: https://git.openjdk.org/jextract/pull/265

From jvernee at openjdk.org  Mon Jan  6 16:29:49 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 6 Jan 2025 16:29:49 GMT
Subject: RFR: 7903917: Changes needed for jdk23-based makefile build [v3]
In-Reply-To: <9cdDJAeZqTSEvKxM0ZVJQF-oJsXGAbqlPuDby9fceGw=.f28bfad4-1216-448d-bb63-69dc2fa15cad@github.com>
References: <N2zZFH5K0mJvIHrnsQO1rdGoG-V9UWijFJ0cfYrjWug=.e3627731-c6ef-4ff8-9d4c-826623abe0d5@github.com>
 <9cdDJAeZqTSEvKxM0ZVJQF-oJsXGAbqlPuDby9fceGw=.f28bfad4-1216-448d-bb63-69dc2fa15cad@github.com>
Message-ID: <xnF4hOY4QgwySefFvrOZ3cgsNGHLiUEFWtsCYz2snFw=.49b5e8f0-73e1-4aba-b5d0-c118fd91cad3@github.com>

On Mon, 6 Jan 2025 16:21:59 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Changes necessary to bump the supported version to JDK 23.
>> Passes tier 1.
>> 
>> Note: This PR will not be integrated before https://github.com/openjdk/jextract/pull/264 as the removal of `--enable-preview` is needed.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into CODETOOLS-7903917
>    
>    # Conflicts:
>    #	make/Build.gmk
>  - remove --release flag
>  - CODETOOLS-7903917

Marked as reviewed by jvernee (Committer).

-------------

PR Review: https://git.openjdk.org/jextract/pull/265#pullrequestreview-2532507854

From nbenalla at openjdk.org  Mon Jan  6 16:40:50 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 6 Jan 2025 16:40:50 GMT
Subject: RFR: 7903917: Changes needed for jdk23-based makefile build [v3]
In-Reply-To: <9cdDJAeZqTSEvKxM0ZVJQF-oJsXGAbqlPuDby9fceGw=.f28bfad4-1216-448d-bb63-69dc2fa15cad@github.com>
References: <N2zZFH5K0mJvIHrnsQO1rdGoG-V9UWijFJ0cfYrjWug=.e3627731-c6ef-4ff8-9d4c-826623abe0d5@github.com>
 <9cdDJAeZqTSEvKxM0ZVJQF-oJsXGAbqlPuDby9fceGw=.f28bfad4-1216-448d-bb63-69dc2fa15cad@github.com>
Message-ID: <yUa9sLJ5y7U61i_ptDT_efrsH4X91GmfZNV-2DkJZIg=.823279dd-1d10-4859-9c52-d24090a7acd8@github.com>

On Mon, 6 Jan 2025 16:21:59 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Changes necessary to bump the supported version to JDK 23.
>> Passes tier 1.
>> 
>> Note: This PR will not be integrated before https://github.com/openjdk/jextract/pull/264 as the removal of `--enable-preview` is needed.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into CODETOOLS-7903917
>    
>    # Conflicts:
>    #	make/Build.gmk
>  - remove --release flag
>  - CODETOOLS-7903917

Thanks Jorn!

-------------

PR Comment: https://git.openjdk.org/jextract/pull/265#issuecomment-2573479300

From duke at openjdk.org  Mon Jan  6 16:40:50 2025
From: duke at openjdk.org (duke)
Date: Mon, 6 Jan 2025 16:40:50 GMT
Subject: RFR: 7903917: Changes needed for jdk23-based makefile build [v3]
In-Reply-To: <9cdDJAeZqTSEvKxM0ZVJQF-oJsXGAbqlPuDby9fceGw=.f28bfad4-1216-448d-bb63-69dc2fa15cad@github.com>
References: <N2zZFH5K0mJvIHrnsQO1rdGoG-V9UWijFJ0cfYrjWug=.e3627731-c6ef-4ff8-9d4c-826623abe0d5@github.com>
 <9cdDJAeZqTSEvKxM0ZVJQF-oJsXGAbqlPuDby9fceGw=.f28bfad4-1216-448d-bb63-69dc2fa15cad@github.com>
Message-ID: <ufIQdLNwxIVgVtVrkyHYdgeYndP5UCsyQmGNWmIyiBI=.3990080e-8025-49da-8b0a-94a213b43192@github.com>

On Mon, 6 Jan 2025 16:21:59 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Changes necessary to bump the supported version to JDK 23.
>> Passes tier 1.
>> 
>> Note: This PR will not be integrated before https://github.com/openjdk/jextract/pull/264 as the removal of `--enable-preview` is needed.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into CODETOOLS-7903917
>    
>    # Conflicts:
>    #	make/Build.gmk
>  - remove --release flag
>  - CODETOOLS-7903917

@nizarbenalla 
Your change (at version 0042ead65647902c08ff3296382137d67aa54faf) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/265#issuecomment-2573480626

From nbenalla at openjdk.org  Mon Jan  6 16:58:51 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 6 Jan 2025 16:58:51 GMT
Subject: Integrated: 7903917: Changes needed for jdk23-based makefile build
In-Reply-To: <N2zZFH5K0mJvIHrnsQO1rdGoG-V9UWijFJ0cfYrjWug=.e3627731-c6ef-4ff8-9d4c-826623abe0d5@github.com>
References: <N2zZFH5K0mJvIHrnsQO1rdGoG-V9UWijFJ0cfYrjWug=.e3627731-c6ef-4ff8-9d4c-826623abe0d5@github.com>
Message-ID: <pEfOzwcEv4ck4fRsA8cec2eoYxzgRMhQXNjOdmJkxDg=.36a1d9d4-1ef9-4d35-8969-bd99ded01ae7@github.com>

On Tue, 17 Dec 2024 16:35:00 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Changes necessary to bump the supported version to JDK 23.
> Passes tier 1.
> 
> Note: This PR will not be integrated before https://github.com/openjdk/jextract/pull/264 as the removal of `--enable-preview` is needed.

This pull request has now been integrated.

Changeset: 0b89a462
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/0b89a462146940a2ec90e34eeb5df3d46d8980d2
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

7903917: Changes needed for jdk23-based makefile build

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jextract/pull/265

From duke at openjdk.org  Mon Jan  6 17:13:49 2025
From: duke at openjdk.org (duke)
Date: Mon, 6 Jan 2025 17:13:49 GMT
Subject: RFR: 7903735: Remove redundant method in generated code [v2]
In-Reply-To: <NWoACNfjw0bEa7nw54pTDXeZ83GQ_3IwTlO6_KX8t8E=.670b2161-0e24-409d-91ae-e7b383e97f1f@github.com>
References: <-Ae7v0nRNZpg81oM4dHk2PYezOoptiRcSFj1TQEX7PA=.df19261c-a8e5-436e-b183-d867b64fd2fd@github.com>
 <NWoACNfjw0bEa7nw54pTDXeZ83GQ_3IwTlO6_KX8t8E=.670b2161-0e24-409d-91ae-e7b383e97f1f@github.com>
Message-ID: <QrITQaYefyHa1PnqoamJGmzj4DChGS-ZTZ7owj4tuqs=.cce73060-6356-4a32-9128-000da4871beb@github.com>

On Thu, 2 Jan 2025 19:18:06 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Was looking at older issues and saw an opportunity for a refractor.
>> I don't see a dependent PR feature for this repo but this is meant to be merged after https://github.com/openjdk/jextract/pull/265
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   (C) 2025

@nizarbenalla 
Your change (at version e6f2842904cc2fde1c49146a9641b22ec08891c8) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/266#issuecomment-2573543341

From nbenalla at openjdk.org  Mon Jan  6 17:13:48 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 6 Jan 2025 17:13:48 GMT
Subject: RFR: 7903735: Remove redundant method in generated code [v2]
In-Reply-To: <NWoACNfjw0bEa7nw54pTDXeZ83GQ_3IwTlO6_KX8t8E=.670b2161-0e24-409d-91ae-e7b383e97f1f@github.com>
References: <-Ae7v0nRNZpg81oM4dHk2PYezOoptiRcSFj1TQEX7PA=.df19261c-a8e5-436e-b183-d867b64fd2fd@github.com>
 <NWoACNfjw0bEa7nw54pTDXeZ83GQ_3IwTlO6_KX8t8E=.670b2161-0e24-409d-91ae-e7b383e97f1f@github.com>
Message-ID: <2WbmZ2GoDDoMLt3zBDr8C9Q9NhuZJktbhNqKq29CpRw=.12f7e9a8-677c-4d0b-a174-8ad6387bfb80@github.com>

On Thu, 2 Jan 2025 19:18:06 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Was looking at older issues and saw an opportunity for a refractor.
>> I don't see a dependent PR feature for this repo but this is meant to be merged after https://github.com/openjdk/jextract/pull/265
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   (C) 2025

This can now be integrated, thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/266#issuecomment-2573542610

From nbenalla at openjdk.org  Mon Jan  6 17:40:50 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 6 Jan 2025 17:40:50 GMT
Subject: Integrated: 7903735: Remove redundant method in generated code
In-Reply-To: <-Ae7v0nRNZpg81oM4dHk2PYezOoptiRcSFj1TQEX7PA=.df19261c-a8e5-436e-b183-d867b64fd2fd@github.com>
References: <-Ae7v0nRNZpg81oM4dHk2PYezOoptiRcSFj1TQEX7PA=.df19261c-a8e5-436e-b183-d867b64fd2fd@github.com>
Message-ID: <fbFmWRJgl6fH2MLwotMYLBnD1bx8_LWojCFMGg1FefY=.e81b36cc-f020-41ad-be94-d2e2a7778a97@github.com>

On Tue, 17 Dec 2024 18:39:19 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Was looking at older issues and saw an opportunity for a refractor.
> I don't see a dependent PR feature for this repo but this is meant to be merged after https://github.com/openjdk/jextract/pull/265

This pull request has now been integrated.

Changeset: a53f5c05
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/a53f5c05e3ee2cca057cadb78b2e381c39f943d7
Stats:     3 lines in 1 file changed: 0 ins; 1 del; 2 mod

7903735: Remove redundant method in generated code

Reviewed-by: jvernee, mcimadamore

-------------

PR: https://git.openjdk.org/jextract/pull/266

From jvernee at openjdk.org  Tue Jan  7 11:43:50 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 7 Jan 2025 11:43:50 GMT
Subject: RFR: 7903926:
 jtreg/generator/testLinkageErrors/TestLinkageErrors.java failed with
 "expected [true] but found [false]"
In-Reply-To: <HPpldKhopNwoj7v73U6K-TXjuDefLGa_AP4eM2fl-DQ=.2cd41d68-d40b-4bad-90e6-ddeb6e12b7c0@github.com>
References: <HPpldKhopNwoj7v73U6K-TXjuDefLGa_AP4eM2fl-DQ=.2cd41d68-d40b-4bad-90e6-ddeb6e12b7c0@github.com>
Message-ID: <haK_VLlV-d7cRS0WqXceOAHA_IEAU_WvKpikmrqbjEc=.cd1b031c-278f-4a9c-809c-9f993ccf3443@github.com>

On Tue, 7 Jan 2025 08:53:40 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to stop a test failure after a53f5c0 because the error message changed.
> 
> Passes tier 1 on all platforms.
> 
> TIA

Marked as reviewed by jvernee (Committer).

-------------

PR Review: https://git.openjdk.org/jextract/pull/270#pullrequestreview-2534125817

From nbenalla at openjdk.org  Tue Jan  7 13:48:50 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 7 Jan 2025 13:48:50 GMT
Subject: RFR: 7903926:
 jtreg/generator/testLinkageErrors/TestLinkageErrors.java failed with
 "expected [true] but found [false]"
In-Reply-To: <HPpldKhopNwoj7v73U6K-TXjuDefLGa_AP4eM2fl-DQ=.2cd41d68-d40b-4bad-90e6-ddeb6e12b7c0@github.com>
References: <HPpldKhopNwoj7v73U6K-TXjuDefLGa_AP4eM2fl-DQ=.2cd41d68-d40b-4bad-90e6-ddeb6e12b7c0@github.com>
Message-ID: <vl7JyTie72G_uwS64usXj747e3OshtYbFdt1s4CIMcU=.54d7290c-6e2b-4f8c-a0d8-f144465bc739@github.com>

On Tue, 7 Jan 2025 08:53:40 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to stop a test failure after a53f5c0 because the error message changed.
> 
> Passes tier 1 on all platforms.
> 
> TIA

Integrating now to stop test failures, here goes.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/270#issuecomment-2575331707

From duke at openjdk.org  Tue Jan  7 13:48:51 2025
From: duke at openjdk.org (duke)
Date: Tue, 7 Jan 2025 13:48:51 GMT
Subject: RFR: 7903926:
 jtreg/generator/testLinkageErrors/TestLinkageErrors.java failed with
 "expected [true] but found [false]"
In-Reply-To: <HPpldKhopNwoj7v73U6K-TXjuDefLGa_AP4eM2fl-DQ=.2cd41d68-d40b-4bad-90e6-ddeb6e12b7c0@github.com>
References: <HPpldKhopNwoj7v73U6K-TXjuDefLGa_AP4eM2fl-DQ=.2cd41d68-d40b-4bad-90e6-ddeb6e12b7c0@github.com>
Message-ID: <cRWy-uZJTTYSQomcham9-EmivjB7pYviDnM9M5r7PBg=.2384a174-9fed-4e63-a83e-ac494de6ecc1@github.com>

On Tue, 7 Jan 2025 08:53:40 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to stop a test failure after a53f5c0 because the error message changed.
> 
> Passes tier 1 on all platforms.
> 
> TIA

@nizarbenalla 
Your change (at version 256408abc37148a808350f20511e2b0deec8ca9e) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/270#issuecomment-2575335532

From nbenalla at openjdk.org  Tue Jan  7 15:28:50 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 7 Jan 2025 15:28:50 GMT
Subject: Integrated: 7903926:
 jtreg/generator/testLinkageErrors/TestLinkageErrors.java failed with
 "expected [true] but found [false]"
In-Reply-To: <HPpldKhopNwoj7v73U6K-TXjuDefLGa_AP4eM2fl-DQ=.2cd41d68-d40b-4bad-90e6-ddeb6e12b7c0@github.com>
References: <HPpldKhopNwoj7v73U6K-TXjuDefLGa_AP4eM2fl-DQ=.2cd41d68-d40b-4bad-90e6-ddeb6e12b7c0@github.com>
Message-ID: <2nsoh8LRQvoUXSbgqBmB15c9Jq_mLEY6uu-fKFFZUWQ=.f7003b7c-742b-47eb-a71c-953f70a4baa6@github.com>

On Tue, 7 Jan 2025 08:53:40 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to stop a test failure after a53f5c0 because the error message changed.
> 
> Passes tier 1 on all platforms.
> 
> TIA

This pull request has now been integrated.

Changeset: 5855b99f
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/5855b99f32a95883f5dae78a6b3e7931925b9784
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

7903926: jtreg/generator/testLinkageErrors/TestLinkageErrors.java failed with "expected [true] but found [false]"

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jextract/pull/270

From sundar at openjdk.org  Thu Jan  9 06:58:35 2025
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Thu, 9 Jan 2025 06:58:35 GMT
Subject: RFR: 7903928: update build.gradle to use JDK 23
Message-ID: <bG0L_6-4sdDc-Wh70u-WJ1dUcHbbZphxxWOIKFVQpEI=.81dcee71-8444-414a-845a-190761081882@github.com>

We've updated native makefile to use JDK 23 (
https://github.com/openjdk/jextract/commit/0b89a462146940a2ec90e34eeb5df3d46d8980d2 )

While build.gradle works & expects jdk 23, it still refers to JDK var as "jdk22_home" and passes --release to be 22. Also jextract version is "22".

-------------

Commit messages:
 - 7903928: update build.gradle to use JDK 23

Changes: https://git.openjdk.org/jextract/pull/271/files
  Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=271&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903928
  Stats: 8 lines in 1 file changed: 1 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jextract/pull/271.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/271/head:pull/271

PR: https://git.openjdk.org/jextract/pull/271

From sundar at openjdk.org  Thu Jan  9 13:31:29 2025
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Thu, 9 Jan 2025 13:31:29 GMT
Subject: RFR: 7903928: update build.gradle to use JDK 23 [v2]
In-Reply-To: <bG0L_6-4sdDc-Wh70u-WJ1dUcHbbZphxxWOIKFVQpEI=.81dcee71-8444-414a-845a-190761081882@github.com>
References: <bG0L_6-4sdDc-Wh70u-WJ1dUcHbbZphxxWOIKFVQpEI=.81dcee71-8444-414a-845a-190761081882@github.com>
Message-ID: <TYix5ZebawaDGn9FCKuuB8-Ez0F7oAiRhJrJjr3_uis=.c25919eb-9a05-4061-b78d-34eeb4e195e7@github.com>

> We've updated native makefile to use JDK 23 (
> https://github.com/openjdk/jextract/commit/0b89a462146940a2ec90e34eeb5df3d46d8980d2 )
> 
> While build.gradle works & expects jdk 23, it still refers to JDK var as "jdk22_home" and passes --release to be 22. Also jextract version is "22".

Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:

  fixed jdk23_home in github test.yml.
  
  changed Python sample so that it does not fail with unsupported type
  _Float16

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/271/files
  - new: https://git.openjdk.org/jextract/pull/271/files/d39ed3c7..d44a111c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=271&range=01
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=271&range=00-01

  Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jextract/pull/271.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/271/head:pull/271

PR: https://git.openjdk.org/jextract/pull/271

From sundar at openjdk.org  Thu Jan  9 13:35:14 2025
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Thu, 9 Jan 2025 13:35:14 GMT
Subject: RFR: 7903928: update build.gradle to use JDK 23 [v3]
In-Reply-To: <bG0L_6-4sdDc-Wh70u-WJ1dUcHbbZphxxWOIKFVQpEI=.81dcee71-8444-414a-845a-190761081882@github.com>
References: <bG0L_6-4sdDc-Wh70u-WJ1dUcHbbZphxxWOIKFVQpEI=.81dcee71-8444-414a-845a-190761081882@github.com>
Message-ID: <Q2ECR7jW18ayC6lr_w95O4m8cHU9JytYGLNUkMqlXWI=.0566c474-7941-4485-afcc-854c9e9425a1@github.com>

> We've updated native makefile to use JDK 23 (
> https://github.com/openjdk/jextract/commit/0b89a462146940a2ec90e34eeb5df3d46d8980d2 )
> 
> While build.gradle works & expects jdk 23, it still refers to JDK var as "jdk22_home" and passes --release to be 22. Also jextract version is "22".

Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:

  missed jdk23_home in test line

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/271/files
  - new: https://git.openjdk.org/jextract/pull/271/files/d44a111c..309d83d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=271&range=02
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=271&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jextract/pull/271.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/271/head:pull/271

PR: https://git.openjdk.org/jextract/pull/271

From jvernee at openjdk.org  Thu Jan  9 14:49:56 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 9 Jan 2025 14:49:56 GMT
Subject: RFR: 7903928: update build.gradle to use JDK 23 [v3]
In-Reply-To: <Q2ECR7jW18ayC6lr_w95O4m8cHU9JytYGLNUkMqlXWI=.0566c474-7941-4485-afcc-854c9e9425a1@github.com>
References: <bG0L_6-4sdDc-Wh70u-WJ1dUcHbbZphxxWOIKFVQpEI=.81dcee71-8444-414a-845a-190761081882@github.com>
 <Q2ECR7jW18ayC6lr_w95O4m8cHU9JytYGLNUkMqlXWI=.0566c474-7941-4485-afcc-854c9e9425a1@github.com>
Message-ID: <DCzEtZ_2kAMkv4JuG5_ArAOy5TFP_kXqi1-HjodVcQ0=.2285855e-0204-4911-adac-f47edfd3436a@github.com>

On Thu, 9 Jan 2025 13:35:14 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> We've updated native makefile to use JDK 23 (
>> https://github.com/openjdk/jextract/commit/0b89a462146940a2ec90e34eeb5df3d46d8980d2 )
>> 
>> While build.gradle works & expects jdk 23, it still refers to JDK var as "jdk22_home" and passes --release to be 22. Also jextract version is "22".
>
> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed jdk23_home in test line

Marked as reviewed by jvernee (Committer).

-------------

PR Review: https://git.openjdk.org/jextract/pull/271#pullrequestreview-2540127886

From liach at openjdk.org  Thu Jan  9 21:23:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 9 Jan 2025 21:23:03 GMT
Subject: RFR: 7903928: update build.gradle to use JDK 23 [v3]
In-Reply-To: <Q2ECR7jW18ayC6lr_w95O4m8cHU9JytYGLNUkMqlXWI=.0566c474-7941-4485-afcc-854c9e9425a1@github.com>
References: <bG0L_6-4sdDc-Wh70u-WJ1dUcHbbZphxxWOIKFVQpEI=.81dcee71-8444-414a-845a-190761081882@github.com>
 <Q2ECR7jW18ayC6lr_w95O4m8cHU9JytYGLNUkMqlXWI=.0566c474-7941-4485-afcc-854c9e9425a1@github.com>
Message-ID: <jrF8dadB9gG1lTjtjZfssiE4AmD5mvWpC3P63y_c74w=.a01df44c-8ae0-4abe-ab89-2a0c09b7f4ed@github.com>

On Thu, 9 Jan 2025 13:35:14 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> We've updated native makefile to use JDK 23 (
>> https://github.com/openjdk/jextract/commit/0b89a462146940a2ec90e34eeb5df3d46d8980d2 )
>> 
>> While build.gradle works & expects jdk 23, it still refers to JDK var as "jdk22_home" and passes --release to be 22. Also jextract version is "22".
>
> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed jdk23_home in test line

build.gradle line 32:

> 30: 
> 31: def llvm_home = project.property("llvm_home")
> 32: def jdk_home = project.property("jdk23_home")

We should rename this property simply to `jdk_home`.

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/271#discussion_r1909445824

From duke at openjdk.org  Thu Jan  9 23:38:51 2025
From: duke at openjdk.org (Marcono1234)
Date: Thu, 9 Jan 2025 23:38:51 GMT
Subject: RFR: Update gradle to version 8.11.1 and fix GitHub actions [v5]
In-Reply-To: <-NGpBS22VQTitzbJUwIF0Z51aw6tCeEOyZz8OAG29v8=.5729fd40-048b-43e5-b9fd-241d3f267534@github.com>
References: <Y7Vc1QeFoSkIY5muQX0Q58h30rttdoFSNFrUtJQu2M0=.cdadeb72-8555-4f03-b1c1-4d2d2e0500cb@github.com>
 <-NGpBS22VQTitzbJUwIF0Z51aw6tCeEOyZz8OAG29v8=.5729fd40-048b-43e5-b9fd-241d3f267534@github.com>
Message-ID: <1CaQktGxXU2K0Wo6JizDjhYrpoBFiMS0Gl50vMTQbkU=.d442a4be-45d2-4ea1-97c1-9168ab0f5176@github.com>

On Mon, 6 Jan 2025 13:00:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Currently the github actions are failing because we depend on versions of the JDK (17 and 22), that are no longer available through the oracle/setup-java github action.
>> 
>> There are 2 barriers to upgrading these JDK version to ones that are supported:
>> 1. The current version of Gradle we are using doesn't run on newer Java versions
>> 2. Due to our use of `--enable-preview` and `--release 22` to compile, we are locked to JDK 22.
>> 
>> This PR updates Gradle to the latest version, which supports running on Java 23. It also drops the `--enable-preview` flag from compilation, which is not actually needed, allowing us to compile using JDK 23 as well. Both these changes then allow us to use JDK 23 to run Gradle, and as a toolchain JDK, in the GitHub actions. Since JDK 23 is available through oracle/setup-java, GitHub actions will work again.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove validate job name to match others

.github/workflows/test.yml line 24:

> 22:         with:
> 23:           fetch-depth: 1
> 24:       - uses: gradle/wrapper-validation-action at v3

`gradle/wrapper-validation-action` is deprecated, and this causes a warning now, see for example https://github.com/JornVernee/jextract/actions/runs/12632919612/job/35197503582#annotation:3:26
> Warning: This job uses deprecated functionality from the 'gradle/wrapper-validation-action' action. Consult the logs for more details.
> DEPRECATION: The action `gradle/wrapper-validation-action` has been replaced by `gradle/actions/wrapper-validation`. See https://github.com/gradle/actions/blob/main/docs/deprecation-upgrade-guide.md#the-action-gradlewrapper-validation-action-has-been-replaced-by-gradleactionswrapper-validation

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/264#discussion_r1909586429

From duke at openjdk.org  Thu Jan  9 23:43:49 2025
From: duke at openjdk.org (Marcono1234)
Date: Thu, 9 Jan 2025 23:43:49 GMT
Subject: RFR: 7903928: update build.gradle to use JDK 23 [v3]
In-Reply-To: <Q2ECR7jW18ayC6lr_w95O4m8cHU9JytYGLNUkMqlXWI=.0566c474-7941-4485-afcc-854c9e9425a1@github.com>
References: <bG0L_6-4sdDc-Wh70u-WJ1dUcHbbZphxxWOIKFVQpEI=.81dcee71-8444-414a-845a-190761081882@github.com>
 <Q2ECR7jW18ayC6lr_w95O4m8cHU9JytYGLNUkMqlXWI=.0566c474-7941-4485-afcc-854c9e9425a1@github.com>
Message-ID: <EqZcI2hUkKCvPoKJkedYqkxKoNiWWM9iZy7NMZzQ42g=.f926e799-393b-4598-be63-c1252e8c54f8@github.com>

On Thu, 9 Jan 2025 13:35:14 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> We've updated native makefile to use JDK 23 (
>> https://github.com/openjdk/jextract/commit/0b89a462146940a2ec90e34eeb5df3d46d8980d2 )
>> 
>> While build.gradle works & expects jdk 23, it still refers to JDK var as "jdk22_home" and passes --release to be 22. Also jextract version is "22".
>
> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed jdk23_home in test line

The `README.md` mentions `jdk22_home` as well and probably needs to be adjusted too.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/271#issuecomment-2581455821

From duke at openjdk.org  Thu Jan  9 23:49:04 2025
From: duke at openjdk.org (Marcono1234)
Date: Thu, 9 Jan 2025 23:49:04 GMT
Subject: RFR: Update gradle to version 8.11.1 and fix GitHub actions [v5]
In-Reply-To: <-NGpBS22VQTitzbJUwIF0Z51aw6tCeEOyZz8OAG29v8=.5729fd40-048b-43e5-b9fd-241d3f267534@github.com>
References: <Y7Vc1QeFoSkIY5muQX0Q58h30rttdoFSNFrUtJQu2M0=.cdadeb72-8555-4f03-b1c1-4d2d2e0500cb@github.com>
 <-NGpBS22VQTitzbJUwIF0Z51aw6tCeEOyZz8OAG29v8=.5729fd40-048b-43e5-b9fd-241d3f267534@github.com>
Message-ID: <ZJ_rHXpnE76iMcOft8_2ONUUWCUKkwXFfh7lYyaA9c0=.38b0de5e-0287-4a5c-a733-90a0cbd25942@github.com>

On Mon, 6 Jan 2025 13:00:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Currently the github actions are failing because we depend on versions of the JDK (17 and 22), that are no longer available through the oracle/setup-java github action.
>> 
>> There are 2 barriers to upgrading these JDK version to ones that are supported:
>> 1. The current version of Gradle we are using doesn't run on newer Java versions
>> 2. Due to our use of `--enable-preview` and `--release 22` to compile, we are locked to JDK 22.
>> 
>> This PR updates Gradle to the latest version, which supports running on Java 23. It also drops the `--enable-preview` flag from compilation, which is not actually needed, allowing us to compile using JDK 23 as well. Both these changes then allow us to use JDK 23 to run Gradle, and as a toolchain JDK, in the GitHub actions. Since JDK 23 is available through oracle/setup-java, GitHub actions will work again.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove validate job name to match others

There is a mention of the Gradle version in the `README.md` which has to be adjusted:
https://github.com/openjdk/jextract/blob/5855b99f32a95883f5dae78a6b3e7931925b9784/README.md?plain=1#L31

-------------

PR Comment: https://git.openjdk.org/jextract/pull/264#issuecomment-2581460280

From jvernee at openjdk.org  Fri Jan 10 10:52:59 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 10 Jan 2025 10:52:59 GMT
Subject: RFR: Update gradle to version 8.11.1 and fix GitHub actions [v5]
In-Reply-To: <1CaQktGxXU2K0Wo6JizDjhYrpoBFiMS0Gl50vMTQbkU=.d442a4be-45d2-4ea1-97c1-9168ab0f5176@github.com>
References: <Y7Vc1QeFoSkIY5muQX0Q58h30rttdoFSNFrUtJQu2M0=.cdadeb72-8555-4f03-b1c1-4d2d2e0500cb@github.com>
 <-NGpBS22VQTitzbJUwIF0Z51aw6tCeEOyZz8OAG29v8=.5729fd40-048b-43e5-b9fd-241d3f267534@github.com>
 <1CaQktGxXU2K0Wo6JizDjhYrpoBFiMS0Gl50vMTQbkU=.d442a4be-45d2-4ea1-97c1-9168ab0f5176@github.com>
Message-ID: <ebSZnvvLNWDc2JCDMpOSksl2kyZpoaMpFwV0VaazTeI=.66fa7892-fbe4-4fb7-8ba4-90e15175ef90@github.com>

On Thu, 9 Jan 2025 23:36:19 GMT, Marcono1234 <duke at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove validate job name to match others
>
> .github/workflows/test.yml line 24:
> 
>> 22:         with:
>> 23:           fetch-depth: 1
>> 24:       - uses: gradle/wrapper-validation-action at v3
> 
> `gradle/wrapper-validation-action` is deprecated, and this causes a warning now, see for example https://github.com/JornVernee/jextract/actions/runs/12632919612/job/35197503582#annotation:3:26
>> Warning: This job uses deprecated functionality from the 'gradle/wrapper-validation-action' action. Consult the logs for more details.
>> DEPRECATION: The action `gradle/wrapper-validation-action` has been replaced by `gradle/actions/wrapper-validation`. See https://github.com/gradle/actions/blob/main/docs/deprecation-upgrade-guide.md#the-action-gradlewrapper-validation-action-has-been-replaced-by-gradleactionswrapper-validation

Oh, I saw that as well, and thought I grabbed the non-deprecated one.

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/264#discussion_r1910200713

From nbenalla at openjdk.org  Mon Jan 13 10:42:11 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 13 Jan 2025 10:42:11 GMT
Subject: RFR: 7903923: Derive C_* layouts directly from the Linker [v3]
In-Reply-To: <KHQsFnZ53No-QEYKtGPfaBe0UrVUCxaxI6_i8rPVNtY=.ec4577b5-f09e-45db-9790-de312a47460f@github.com>
References: <KHQsFnZ53No-QEYKtGPfaBe0UrVUCxaxI6_i8rPVNtY=.ec4577b5-f09e-45db-9790-de312a47460f@github.com>
Message-ID: <uXfexqO8ljElJGQjtxiBNqgqnjw8_dRUEB_QF0f8v-c=.40198dbd-4fd7-4f33-9dc3-687ed3942c31@github.com>

> Depending on the platform, different `C_*`  correspond to different `JAVA_*` types. We can get those values directly from the linker.
> 
> This patch can allows us to have a common class for different platforms.
> 
> Please review, and thanks in advance!

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - use the canonical layout "long long" for C_LONG_LONG
 - Merge remote-tracking branch 'upstream/master' into derive-C-layours-from-linker-p
 - Fix the C_LONG layout in windows
 - derive "C" types directly from the linker

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/269/files
  - new: https://git.openjdk.org/jextract/pull/269/files/ed192bbf..461d714f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=269&range=02
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=269&range=01-02

  Stats: 85 lines in 10 files changed: 37 ins; 6 del; 42 mod
  Patch: https://git.openjdk.org/jextract/pull/269.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/269/head:pull/269

PR: https://git.openjdk.org/jextract/pull/269

From nbenalla at openjdk.org  Mon Jan 13 11:37:00 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 13 Jan 2025 11:37:00 GMT
Subject: RFR: 7903923: Derive C_* layouts directly from the Linker [v3]
In-Reply-To: <uXfexqO8ljElJGQjtxiBNqgqnjw8_dRUEB_QF0f8v-c=.40198dbd-4fd7-4f33-9dc3-687ed3942c31@github.com>
References: <KHQsFnZ53No-QEYKtGPfaBe0UrVUCxaxI6_i8rPVNtY=.ec4577b5-f09e-45db-9790-de312a47460f@github.com>
 <uXfexqO8ljElJGQjtxiBNqgqnjw8_dRUEB_QF0f8v-c=.40198dbd-4fd7-4f33-9dc3-687ed3942c31@github.com>
Message-ID: <2VfrR-nlMKzbRmpvUcWQcOQQ5KtXl8NEFZz0kuXeGUQ=.ca8b383d-31d4-4bba-8408-58bc50b95a4d@github.com>

On Mon, 13 Jan 2025 10:42:11 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Depending on the platform, different `C_*`  correspond to different `JAVA_*` types. We can get those values directly from the linker.
>> 
>> This patch can allows us to have a common class for different platforms.
>> 
>> Please review, and thanks in advance!
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - use the canonical layout "long long" for C_LONG_LONG
>  - Merge remote-tracking branch 'upstream/master' into derive-C-layours-from-linker-p
>  - Fix the C_LONG layout in windows
>  - derive "C" types directly from the linker

I now use the correct layout for `C_LONG_LONG`. Passes tier 1 on Mac and Windows.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/269#issuecomment-2586863701

From mcimadamore at openjdk.org  Mon Jan 13 12:23:56 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 Jan 2025 12:23:56 GMT
Subject: RFR: 7903923: Derive C_* layouts directly from the Linker [v3]
In-Reply-To: <uXfexqO8ljElJGQjtxiBNqgqnjw8_dRUEB_QF0f8v-c=.40198dbd-4fd7-4f33-9dc3-687ed3942c31@github.com>
References: <KHQsFnZ53No-QEYKtGPfaBe0UrVUCxaxI6_i8rPVNtY=.ec4577b5-f09e-45db-9790-de312a47460f@github.com>
 <uXfexqO8ljElJGQjtxiBNqgqnjw8_dRUEB_QF0f8v-c=.40198dbd-4fd7-4f33-9dc3-687ed3942c31@github.com>
Message-ID: <Xw6SGz-5it6zD5bJcwz0O4-3qhtNU2yxR_v4edtUH4E=.e5e9ac92-b22b-4889-9b1d-552d2201166f@github.com>

On Mon, 13 Jan 2025 10:42:11 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Depending on the platform, different `C_*`  correspond to different `JAVA_*` types. We can get those values directly from the linker.
>> 
>> This patch can allows us to have a common class for different platforms.
>> 
>> Please review, and thanks in advance!
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - use the canonical layout "long long" for C_LONG_LONG
>  - Merge remote-tracking branch 'upstream/master' into derive-C-layours-from-linker-p
>  - Fix the C_LONG layout in windows
>  - derive "C" types directly from the linker

What's the story with primitive typedef? Do they work? I believe they will go back to stuff like JAVA_INT and such, instead of picking the layout constant we have already emitted. E.g. 

`typedef int myInt`

-------------

PR Comment: https://git.openjdk.org/jextract/pull/269#issuecomment-2586961790

From mcimadamore at openjdk.org  Mon Jan 13 12:26:49 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 Jan 2025 12:26:49 GMT
Subject: RFR: 7903923: Derive C_* layouts directly from the Linker [v3]
In-Reply-To: <Xw6SGz-5it6zD5bJcwz0O4-3qhtNU2yxR_v4edtUH4E=.e5e9ac92-b22b-4889-9b1d-552d2201166f@github.com>
References: <KHQsFnZ53No-QEYKtGPfaBe0UrVUCxaxI6_i8rPVNtY=.ec4577b5-f09e-45db-9790-de312a47460f@github.com>
 <uXfexqO8ljElJGQjtxiBNqgqnjw8_dRUEB_QF0f8v-c=.40198dbd-4fd7-4f33-9dc3-687ed3942c31@github.com>
 <Xw6SGz-5it6zD5bJcwz0O4-3qhtNU2yxR_v4edtUH4E=.e5e9ac92-b22b-4889-9b1d-552d2201166f@github.com>
Message-ID: <UGw7VEfhYw16T1V1gx6x0fQzAFj4-Z_3Pv6wauUXkuA=.e23761ad-ec7b-4b07-90f6-6e8391234da3@github.com>

On Mon, 13 Jan 2025 12:21:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> What's the story with primitive typedef? Do they work? I believe they will go back to stuff like JAVA_INT and such, instead of picking the layout constant we have already emitted. E.g.
> 
> `typedef int myInt`

I think to address this, the method ClassSourceBuilder::primitiveLayoutString might come in useful, as we use that method to generate references to primitive layouts e.g. inside struct layout declarations.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/269#issuecomment-2586967055

From nbenalla at openjdk.org  Mon Jan 13 17:35:00 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 13 Jan 2025 17:35:00 GMT
Subject: RFR: 7903923: Derive C_* layouts directly from the Linker [v3]
In-Reply-To: <UGw7VEfhYw16T1V1gx6x0fQzAFj4-Z_3Pv6wauUXkuA=.e23761ad-ec7b-4b07-90f6-6e8391234da3@github.com>
References: <KHQsFnZ53No-QEYKtGPfaBe0UrVUCxaxI6_i8rPVNtY=.ec4577b5-f09e-45db-9790-de312a47460f@github.com>
 <uXfexqO8ljElJGQjtxiBNqgqnjw8_dRUEB_QF0f8v-c=.40198dbd-4fd7-4f33-9dc3-687ed3942c31@github.com>
 <Xw6SGz-5it6zD5bJcwz0O4-3qhtNU2yxR_v4edtUH4E=.e5e9ac92-b22b-4889-9b1d-552d2201166f@github.com>
 <UGw7VEfhYw16T1V1gx6x0fQzAFj4-Z_3Pv6wauUXkuA=.e23761ad-ec7b-4b07-90f6-6e8391234da3@github.com>
Message-ID: <AlhsblOeqJ6Z4WiElEKZXZrs6rWBODTbn98pgKMe5yU=.d6e71887-b92c-409b-971b-e34b82ec5c36@github.com>

On Mon, 13 Jan 2025 12:24:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> What's the story with primitive typedef? Do they work? I believe they will go back to stuff like JAVA_INT and such, instead of picking the layout constant we have already emitted. E.g.
>
> typedef int myInt

I do not think so. Instead `C_INT` derived from the canonical layout is used everywhere


cat test.h 
typedef long myLong;
typedef int myInt;

`jextract` generates the following code 


public static final OfLong myLong = test_h.C_LONG;
public static final OfInt myInt = test_h.C_INT;

I generated a couple of samples (sqlite3 and opengl) and do not see `JAVA_INT` anywhere, the only place where this string is found in the repo is the generated libclang folder.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/269#issuecomment-2587748293

From nbenalla at openjdk.org  Mon Jan 13 17:49:44 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 13 Jan 2025 17:49:44 GMT
Subject: RFR: 7903923: Derive C_* layouts directly from the Linker [v4]
In-Reply-To: <KHQsFnZ53No-QEYKtGPfaBe0UrVUCxaxI6_i8rPVNtY=.ec4577b5-f09e-45db-9790-de312a47460f@github.com>
References: <KHQsFnZ53No-QEYKtGPfaBe0UrVUCxaxI6_i8rPVNtY=.ec4577b5-f09e-45db-9790-de312a47460f@github.com>
Message-ID: <cLNaK6S1bs-6hOrio1NoKnmFsT-na0a2_IqiEv92Vpc=.dc313449-11ef-4262-8609-4d6691c47b8f@github.com>

> Depending on the platform, different `C_*`  correspond to different `JAVA_*` types. We can get those values directly from the linker.
> 
> This patch can allows us to have a common class for different platforms.
> 
> Please review, and thanks in advance!

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  Drop the use of JAVA_BYTE and add a small whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/269/files
  - new: https://git.openjdk.org/jextract/pull/269/files/461d714f..f879022f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=269&range=03
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=269&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jextract/pull/269.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/269/head:pull/269

PR: https://git.openjdk.org/jextract/pull/269

From nbenalla at openjdk.org  Mon Jan 13 17:49:46 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 13 Jan 2025 17:49:46 GMT
Subject: RFR: 7903923: Derive C_* layouts directly from the Linker [v3]
In-Reply-To: <uXfexqO8ljElJGQjtxiBNqgqnjw8_dRUEB_QF0f8v-c=.40198dbd-4fd7-4f33-9dc3-687ed3942c31@github.com>
References: <KHQsFnZ53No-QEYKtGPfaBe0UrVUCxaxI6_i8rPVNtY=.ec4577b5-f09e-45db-9790-de312a47460f@github.com>
 <uXfexqO8ljElJGQjtxiBNqgqnjw8_dRUEB_QF0f8v-c=.40198dbd-4fd7-4f33-9dc3-687ed3942c31@github.com>
Message-ID: <3B3-tZhwWSE-CFWWUAGBN5uPb4smxZDSujoquGJBAzo=.f9f27210-4173-4929-9f7b-211a06f62e0f@github.com>

On Mon, 13 Jan 2025 10:42:11 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Depending on the platform, different `C_*`  correspond to different `JAVA_*` types. We can get those values directly from the linker.
>> 
>> This patch can allows us to have a common class for different platforms.
>> 
>> Please review, and thanks in advance!
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - use the canonical layout "long long" for C_LONG_LONG
>  - Merge remote-tracking branch 'upstream/master' into derive-C-layours-from-linker-p
>  - Fix the C_LONG layout in windows
>  - derive "C" types directly from the linker

Made a small change, I wanted to drop the last usage of `JAVA_*` that remained.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/269#issuecomment-2587778336

From nbenalla at openjdk.org  Mon Jan 13 18:05:23 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 13 Jan 2025 18:05:23 GMT
Subject: RFR: 7903922: Update copyright year for jextract in files where it
 was missed [v7]
In-Reply-To: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
References: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
Message-ID: <wewZZCdwFILiCgD6J7IyCGolRoq6T6A324CndxoUUaY=.da025f60-670b-4244-9098-5f8526685518@github.com>

> I have sampled a few files to manually check that this works as intended, I got the list of files changed in a certain year by running.
> 
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > 2024file.list
> git log --oneline --since="1/1/2023" --until="31/12/2023" --name-only --pretty=format: | sort -u > 2023file.list
> 
> 
> And then used a script to update the copyright year, I did a random sampling of files to check that it worked as intended.
> 
> A few files had their original copyright year changed because I noticed they were added in 2024 instead.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Update copyright of files updated in this PR to 2024"
  
  This reverts commit b334ad01fab137f4aa05dd7ebbdf7c12fd79dbd9.

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/267/files
  - new: https://git.openjdk.org/jextract/pull/267/files/b334ad01..624f66e4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=267&range=06
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=267&range=05-06

  Stats: 67 lines in 67 files changed: 0 ins; 0 del; 67 mod
  Patch: https://git.openjdk.org/jextract/pull/267.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/267/head:pull/267

PR: https://git.openjdk.org/jextract/pull/267

From jvernee at openjdk.org  Mon Jan 13 18:05:59 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 13 Jan 2025 18:05:59 GMT
Subject: RFR: 7903923: Derive C_* layouts directly from the Linker [v4]
In-Reply-To: <cLNaK6S1bs-6hOrio1NoKnmFsT-na0a2_IqiEv92Vpc=.dc313449-11ef-4262-8609-4d6691c47b8f@github.com>
References: <KHQsFnZ53No-QEYKtGPfaBe0UrVUCxaxI6_i8rPVNtY=.ec4577b5-f09e-45db-9790-de312a47460f@github.com>
 <cLNaK6S1bs-6hOrio1NoKnmFsT-na0a2_IqiEv92Vpc=.dc313449-11ef-4262-8609-4d6691c47b8f@github.com>
Message-ID: <CjoWzCoQv5USHRxhFCFsDg4atomrGnBd-VCtNtInPjA=.2915a239-9e1e-4bfd-89d6-86e0fea499ac@github.com>

On Mon, 13 Jan 2025 17:49:44 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Depending on the platform, different `C_*`  correspond to different `JAVA_*` types. We can get those values directly from the linker.
>> 
>> This patch can allows us to have a common class for different platforms.
>> 
>> Please review, and thanks in advance!
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop the use of JAVA_BYTE and add a small whitespace

Latest version looks good. Thanks!

-------------

Marked as reviewed by jvernee (Committer).

PR Review: https://git.openjdk.org/jextract/pull/269#pullrequestreview-2547395897

From jvernee at openjdk.org  Mon Jan 13 18:08:53 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 13 Jan 2025 18:08:53 GMT
Subject: RFR: 7903922: Update copyright year for jextract in files where it
 was missed [v7]
In-Reply-To: <wewZZCdwFILiCgD6J7IyCGolRoq6T6A324CndxoUUaY=.da025f60-670b-4244-9098-5f8526685518@github.com>
References: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
 <wewZZCdwFILiCgD6J7IyCGolRoq6T6A324CndxoUUaY=.da025f60-670b-4244-9098-5f8526685518@github.com>
Message-ID: <TuX8iJxdWAIHeM82W3-CxRNTJd41BCz3vqUh8R8IJ4k=.0555f84f-25fe-45d0-a5ea-ee4e6a96fbdb@github.com>

On Mon, 13 Jan 2025 18:05:23 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> I have sampled a few files to manually check that this works as intended, I got the list of files changed in a certain year by running.
>> 
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > 2024file.list
>> git log --oneline --since="1/1/2023" --until="31/12/2023" --name-only --pretty=format: | sort -u > 2023file.list
>> 
>> 
>> And then used a script to update the copyright year, I did a random sampling of files to check that it worked as intended.
>> 
>> A few files had their original copyright year changed because I noticed they were added in 2024 instead.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Update copyright of files updated in this PR to 2024"
>   
>   This reverts commit b334ad01fab137f4aa05dd7ebbdf7c12fd79dbd9.

Marked as reviewed by jvernee (Committer).

-------------

PR Review: https://git.openjdk.org/jextract/pull/267#pullrequestreview-2547405651

From nbenalla at openjdk.org  Mon Jan 13 18:08:53 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 13 Jan 2025 18:08:53 GMT
Subject: RFR: 7903922: Update copyright year for jextract in files where it
 was missed [v6]
In-Reply-To: <ts4V9ohumTvC7gUH6ZcbdhO5nEt2b82eMtx0LCr95PU=.e5d2e1a5-598f-4521-9bb6-a0d8dacecae1@github.com>
References: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
 <ts4V9ohumTvC7gUH6ZcbdhO5nEt2b82eMtx0LCr95PU=.e5d2e1a5-598f-4521-9bb6-a0d8dacecae1@github.com>
Message-ID: <qnDeYynZg2BluaKWpnSwRB3mk01VZ9PY58q9VUlYXyg=.d28b6c5d-0023-409c-bc79-9acb80b0897e@github.com>

On Thu, 2 Jan 2025 21:18:33 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> I have sampled a few files to manually check that this works as intended, I got the list of files changed in a certain year by running.
>> 
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > 2024file.list
>> git log --oneline --since="1/1/2023" --until="31/12/2023" --name-only --pretty=format: | sort -u > 2023file.list
>> 
>> 
>> And then used a script to update the copyright year, I did a random sampling of files to check that it worked as intended.
>> 
>> A few files had their original copyright year changed because I noticed they were added in 2024 instead.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright of files updated in this PR to 2024

Reverted the change bumping the copyright years to 2025. The copyright years interval now matches the last change made to the file.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/267#issuecomment-2587827156

From mcimadamore at openjdk.org  Mon Jan 13 18:54:52 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 Jan 2025 18:54:52 GMT
Subject: RFR: 7903923: Derive C_* layouts directly from the Linker [v4]
In-Reply-To: <cLNaK6S1bs-6hOrio1NoKnmFsT-na0a2_IqiEv92Vpc=.dc313449-11ef-4262-8609-4d6691c47b8f@github.com>
References: <KHQsFnZ53No-QEYKtGPfaBe0UrVUCxaxI6_i8rPVNtY=.ec4577b5-f09e-45db-9790-de312a47460f@github.com>
 <cLNaK6S1bs-6hOrio1NoKnmFsT-na0a2_IqiEv92Vpc=.dc313449-11ef-4262-8609-4d6691c47b8f@github.com>
Message-ID: <6ER7KLaGOAjEW4jXDZEMkeE79_dHTqM1iBKcW42ONyo=.b8d96a73-e3eb-485b-ab9e-31aa1cd3284f@github.com>

On Mon, 13 Jan 2025 17:49:44 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Depending on the platform, different `C_*`  correspond to different `JAVA_*` types. We can get those values directly from the linker.
>> 
>> This patch can allows us to have a common class for different platforms.
>> 
>> Please review, and thanks in advance!
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop the use of JAVA_BYTE and add a small whitespace

Looks good!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jextract/pull/269#pullrequestreview-2547553789

From jvernee at openjdk.org  Tue Jan 14 11:19:32 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 14 Jan 2025 11:19:32 GMT
Subject: RFR: Gradle 8.11.1 update cleanups
Message-ID: <tw0Ey7lH6tA05A-E2WvIlOXXifFgXOBCZ1ube3eTO_Y=.7edea303-7656-4509-a5d3-20d212d85fb1@github.com>

Some things were missed as part of: https://github.com/openjdk/jextract/pull/264

- The action to validate the gradle wrapper accidentally uses a deprecated version
- The readme was not updated.

-------------

Commit messages:
 - update readme
 - use non-deprecated action to validate gradle wrapper

Changes: https://git.openjdk.org/jextract/pull/272/files
  Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=272&range=00
  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jextract/pull/272.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/272/head:pull/272

PR: https://git.openjdk.org/jextract/pull/272

From mcimadamore at openjdk.org  Wed Jan 15 09:27:50 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 15 Jan 2025 09:27:50 GMT
Subject: RFR: 7903928: update build.gradle to use JDK 23 [v3]
In-Reply-To: <jrF8dadB9gG1lTjtjZfssiE4AmD5mvWpC3P63y_c74w=.a01df44c-8ae0-4abe-ab89-2a0c09b7f4ed@github.com>
References: <bG0L_6-4sdDc-Wh70u-WJ1dUcHbbZphxxWOIKFVQpEI=.81dcee71-8444-414a-845a-190761081882@github.com>
 <Q2ECR7jW18ayC6lr_w95O4m8cHU9JytYGLNUkMqlXWI=.0566c474-7941-4485-afcc-854c9e9425a1@github.com>
 <jrF8dadB9gG1lTjtjZfssiE4AmD5mvWpC3P63y_c74w=.a01df44c-8ae0-4abe-ab89-2a0c09b7f4ed@github.com>
Message-ID: <NT7tktzkTdeveZi615ecmy7zgumjt4QFz4-qKirMAOQ=.160c150e-2d87-4fc5-ae8b-eba25e04a391@github.com>

On Thu, 9 Jan 2025 21:20:35 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   missed jdk23_home in test line
>
> build.gradle line 32:
> 
>> 30: 
>> 31: def llvm_home = project.property("llvm_home")
>> 32: def jdk_home = project.property("jdk23_home")
> 
> We should rename this property simply to `jdk_home`.

I agree. Especially now that we only have one "master" (tip) version.

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/271#discussion_r1916221595

From nbenalla at openjdk.org  Wed Jan 15 09:35:53 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 15 Jan 2025 09:35:53 GMT
Subject: RFR: 7903923: Derive C_* layouts directly from the Linker [v4]
In-Reply-To: <cLNaK6S1bs-6hOrio1NoKnmFsT-na0a2_IqiEv92Vpc=.dc313449-11ef-4262-8609-4d6691c47b8f@github.com>
References: <KHQsFnZ53No-QEYKtGPfaBe0UrVUCxaxI6_i8rPVNtY=.ec4577b5-f09e-45db-9790-de312a47460f@github.com>
 <cLNaK6S1bs-6hOrio1NoKnmFsT-na0a2_IqiEv92Vpc=.dc313449-11ef-4262-8609-4d6691c47b8f@github.com>
Message-ID: <fPS_hhNMKKR877NiLVJCN2CGofjH_07p7nAOktoyWCI=.b59e69dd-03b8-47e1-95b8-c252f60a7a2a@github.com>

On Mon, 13 Jan 2025 17:49:44 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Depending on the platform, different `C_*`  correspond to different `JAVA_*` types. We can get those values directly from the linker.
>> 
>> This patch can allows us to have a common class for different platforms.
>> 
>> Please review, and thanks in advance!
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop the use of JAVA_BYTE and add a small whitespace

Thanks all for the reviews on this.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/269#issuecomment-2592116332

From duke at openjdk.org  Wed Jan 15 09:35:53 2025
From: duke at openjdk.org (duke)
Date: Wed, 15 Jan 2025 09:35:53 GMT
Subject: RFR: 7903923: Derive C_* layouts directly from the Linker [v4]
In-Reply-To: <cLNaK6S1bs-6hOrio1NoKnmFsT-na0a2_IqiEv92Vpc=.dc313449-11ef-4262-8609-4d6691c47b8f@github.com>
References: <KHQsFnZ53No-QEYKtGPfaBe0UrVUCxaxI6_i8rPVNtY=.ec4577b5-f09e-45db-9790-de312a47460f@github.com>
 <cLNaK6S1bs-6hOrio1NoKnmFsT-na0a2_IqiEv92Vpc=.dc313449-11ef-4262-8609-4d6691c47b8f@github.com>
Message-ID: <MVx1Zj_gbBEG9Q9gJOAyid0xRCreFJNOVPh0QZFOhIo=.5dd83408-7be3-40aa-8b3a-635e9d5bb3d7@github.com>

On Mon, 13 Jan 2025 17:49:44 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Depending on the platform, different `C_*`  correspond to different `JAVA_*` types. We can get those values directly from the linker.
>> 
>> This patch can allows us to have a common class for different platforms.
>> 
>> Please review, and thanks in advance!
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop the use of JAVA_BYTE and add a small whitespace

@nizarbenalla 
Your change (at version f879022f9f7d58b501f1c42339172668c41b12d3) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/269#issuecomment-2592119910

From sundar at openjdk.org  Wed Jan 15 09:51:05 2025
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Wed, 15 Jan 2025 09:51:05 GMT
Subject: RFR: 7903928: update build.gradle to use JDK 23 [v3]
In-Reply-To: <NT7tktzkTdeveZi615ecmy7zgumjt4QFz4-qKirMAOQ=.160c150e-2d87-4fc5-ae8b-eba25e04a391@github.com>
References: <bG0L_6-4sdDc-Wh70u-WJ1dUcHbbZphxxWOIKFVQpEI=.81dcee71-8444-414a-845a-190761081882@github.com>
 <Q2ECR7jW18ayC6lr_w95O4m8cHU9JytYGLNUkMqlXWI=.0566c474-7941-4485-afcc-854c9e9425a1@github.com>
 <jrF8dadB9gG1lTjtjZfssiE4AmD5mvWpC3P63y_c74w=.a01df44c-8ae0-4abe-ab89-2a0c09b7f4ed@github.com>
 <NT7tktzkTdeveZi615ecmy7zgumjt4QFz4-qKirMAOQ=.160c150e-2d87-4fc5-ae8b-eba25e04a391@github.com>
Message-ID: <8Yz068JJlNEUWwp8kYxp7_4Eym2NXZvudlYs3bwM78E=.77fca95b-5534-4ffa-a979-b305aaa96cf4@github.com>

On Wed, 15 Jan 2025 09:24:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> build.gradle line 32:
>> 
>>> 30: 
>>> 31: def llvm_home = project.property("llvm_home")
>>> 32: def jdk_home = project.property("jdk23_home")
>> 
>> We should rename this property simply to `jdk_home`.
>
> I agree. Especially now that we only have one "master" (tip) version.

Gradle's jdk is set via JAVA_HOME. It is usual have gradle support for the latest JDK to come bit "late". If we call JDK needed for jextract to be "jdk_Home" and the one needed for gradle as "JAVA_HOME", we may be in a situation where jdk_home points latest JDK (say JDK 25) and JAVA_HOME points whatever then latest Gradle supports. Can we keep jextract use specific JDK version for its build/test as a separately distinctly named variable?

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/271#discussion_r1916256236

From liach at openjdk.org  Wed Jan 15 15:42:06 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 15 Jan 2025 15:42:06 GMT
Subject: RFR: 7903928: update build.gradle to use JDK 23 [v3]
In-Reply-To: <8Yz068JJlNEUWwp8kYxp7_4Eym2NXZvudlYs3bwM78E=.77fca95b-5534-4ffa-a979-b305aaa96cf4@github.com>
References: <bG0L_6-4sdDc-Wh70u-WJ1dUcHbbZphxxWOIKFVQpEI=.81dcee71-8444-414a-845a-190761081882@github.com>
 <Q2ECR7jW18ayC6lr_w95O4m8cHU9JytYGLNUkMqlXWI=.0566c474-7941-4485-afcc-854c9e9425a1@github.com>
 <jrF8dadB9gG1lTjtjZfssiE4AmD5mvWpC3P63y_c74w=.a01df44c-8ae0-4abe-ab89-2a0c09b7f4ed@github.com>
 <NT7tktzkTdeveZi615ecmy7zgumjt4QFz4-qKirMAOQ=.160c150e-2d87-4fc5-ae8b-eba25e04a391@github.com>
 <8Yz068JJlNEUWwp8kYxp7_4Eym2NXZvudlYs3bwM78E=.77fca95b-5534-4ffa-a979-b305aaa96cf4@github.com>
Message-ID: <crFHqutjURpfNj3xQAb2bYR98GvgTAvbX6RpwBb3jeU=.f2c6b694-c16c-4c0e-956a-9d0ad3ff8029@github.com>

On Wed, 15 Jan 2025 09:48:30 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> I agree. Especially now that we only have one "master" (tip) version.
>
> Gradle's jdk is set via JAVA_HOME. It is usual have gradle support for the latest JDK to come bit "late". If we call JDK needed for jextract to be "jdk_Home" and the one needed for gradle as "JAVA_HOME", we may be in a situation where jdk_home points latest JDK (say JDK 25) and JAVA_HOME points whatever then latest Gradle supports. Can we keep jextract use specific JDK version for its build/test as a separately distinctly named variable?

I think you can run gradle's Java compilation and the gradle tool with different JDKs; my previous strategy for running JMH through gradle was to define my local openjdk build as `org.gradle.java.home` project property, either set in gradle.properties or passed as `-Porg.gradle.java.home=xx` on command line. `JAVA_HOME` is used to launch the gradle tool, so it cannot be the local openjdk build, which uses a class file format too new for gradle to generate abstract method implementations.

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/271#discussion_r1916876368

From nbenalla at openjdk.org  Wed Jan 15 22:54:48 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 15 Jan 2025 22:54:48 GMT
Subject: Integrated: 7903923: Derive C_* layouts directly from the Linker
In-Reply-To: <KHQsFnZ53No-QEYKtGPfaBe0UrVUCxaxI6_i8rPVNtY=.ec4577b5-f09e-45db-9790-de312a47460f@github.com>
References: <KHQsFnZ53No-QEYKtGPfaBe0UrVUCxaxI6_i8rPVNtY=.ec4577b5-f09e-45db-9790-de312a47460f@github.com>
Message-ID: <ljeaV8GNXwiTRvLoKB5pG2Uk0QzFUoqPc_AQX7ILbEI=.c6d73396-d92f-4b23-be69-715b2b51417c@github.com>

On Mon, 30 Dec 2024 16:16:41 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Depending on the platform, different `C_*`  correspond to different `JAVA_*` types. We can get those values directly from the linker.
> 
> This patch can allows us to have a common class for different platforms.
> 
> Please review, and thanks in advance!

This pull request has now been integrated.

Changeset: 1c614f31
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/1c614f31fac9e6309e8d3498a128ac9484348c85
Stats:     13 lines in 1 file changed: 0 ins; 0 del; 13 mod

7903923: Derive C_* layouts directly from the Linker

Reviewed-by: jvernee, mcimadamore

-------------

PR: https://git.openjdk.org/jextract/pull/269

From nbenalla at openjdk.org  Thu Jan 16 12:44:32 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 16 Jan 2025 12:44:32 GMT
Subject: RFR: 7903925: Only the main generated header class should be public
Message-ID: <NJpBXGlB7-5sSF0RQQsVYsA3FlOpZXSaIhq7jOtEl7k=.bd3df890-617b-4586-aee9-8a12229c4246@github.com>

Please review this patch to make the different header classes jextract generates (e.g. foo_h, foo_h_1, foo_h_2, ...) into package-private classes, leaving the main header class (without prefixes) as the only public class.

While reading the sources, I noticed what seems like small bug in `SourceFileBuilder` introduced in https://github.com/openjdk/jextract/commit/a699148238fad919390d67eeb73805e780a518e8 so I fixed it as part of this patch.

TIA.

-------------

Commit messages:
 - consider numbered header classes as part of the implementation

Changes: https://git.openjdk.org/jextract/pull/273/files
  Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=273&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903925
  Stats: 23 lines in 2 files changed: 8 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jextract/pull/273.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/273/head:pull/273

PR: https://git.openjdk.org/jextract/pull/273

From nbenalla at openjdk.org  Fri Jan 17 08:07:59 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 17 Jan 2025 08:07:59 GMT
Subject: RFR: 7903932: Make private static classes final and have a private
 constructor
Message-ID: <NvNwHzwH_tAcc7n1JF0iX5-0jm0-XzE_yomBwFyLt6Q=.132e90ee-6df2-460f-9a5d-bf1e2a56f718@github.com>

Please review this patch to make static utility classes final with a private constructor, as they are not meant to be extended.

This is a small refractor of the generated code.

TIA

-------------

Commit messages:
 - fix whitespace errors and add blank line
 - make private utility classes final with a private constructor

Changes: https://git.openjdk.org/jextract/pull/274/files
  Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=274&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903932
  Stats: 12 lines in 1 file changed: 9 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jextract/pull/274.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/274/head:pull/274

PR: https://git.openjdk.org/jextract/pull/274

From mcimadamore at openjdk.org  Fri Jan 17 11:38:53 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jan 2025 11:38:53 GMT
Subject: RFR: 7903932: Make private static classes final and have a private
 constructor
In-Reply-To: <NvNwHzwH_tAcc7n1JF0iX5-0jm0-XzE_yomBwFyLt6Q=.132e90ee-6df2-460f-9a5d-bf1e2a56f718@github.com>
References: <NvNwHzwH_tAcc7n1JF0iX5-0jm0-XzE_yomBwFyLt6Q=.132e90ee-6df2-460f-9a5d-bf1e2a56f718@github.com>
Message-ID: <w-w1g1T4yNmnOMey6NqQs2lpfzDmQ176T5wkQ8SSu-c=.35f2fd11-bc3c-45b8-9d81-f75d4f2ecbd2@github.com>

On Fri, 17 Jan 2025 07:41:53 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to make static utility classes final with a private constructor, as they are not meant to be extended.
> 
> This is a small refractor of the generated code.
> 
> TIA

While I don't object to the refactoring, I feel ambivalent about it. These classes are private, so it's impossible for jextract clients to do anything with them. What do the extra constructor and extra finality add? It only seems to protect against the event that jextract itself will generate code extending this classes, which seems a corner^4 case.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/274#issuecomment-2598171344

From mcimadamore at openjdk.org  Fri Jan 17 11:45:51 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jan 2025 11:45:51 GMT
Subject: RFR: 7903925: Only the main generated header class should be
 public
In-Reply-To: <NJpBXGlB7-5sSF0RQQsVYsA3FlOpZXSaIhq7jOtEl7k=.bd3df890-617b-4586-aee9-8a12229c4246@github.com>
References: <NJpBXGlB7-5sSF0RQQsVYsA3FlOpZXSaIhq7jOtEl7k=.bd3df890-617b-4586-aee9-8a12229c4246@github.com>
Message-ID: <u1hgwEJCZ2s8H_qWAbQHF6RNsdFY_b1KaTRQmKs9gqM=.26e2024d-e910-4c06-abc9-34575e92f841@github.com>

On Thu, 16 Jan 2025 12:22:12 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to make the different header classes jextract generates (e.g. foo_h, foo_h_1, foo_h_2, ...) into package-private classes, leaving the main header class (without prefixes) as the only public class.
> 
> While reading the sources, I noticed what seems like small bug in `SourceFileBuilder` introduced in https://github.com/openjdk/jextract/commit/a699148238fad919390d67eeb73805e780a518e8 so I fixed it as part of this patch.
> 
> TIA.

Looks good, thanks!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jextract/pull/273#pullrequestreview-2558812501

From nbenalla at openjdk.org  Fri Jan 17 12:08:59 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 17 Jan 2025 12:08:59 GMT
Subject: RFR: 7903932: Make private static classes final and have a private
 constructor
In-Reply-To: <NvNwHzwH_tAcc7n1JF0iX5-0jm0-XzE_yomBwFyLt6Q=.132e90ee-6df2-460f-9a5d-bf1e2a56f718@github.com>
References: <NvNwHzwH_tAcc7n1JF0iX5-0jm0-XzE_yomBwFyLt6Q=.132e90ee-6df2-460f-9a5d-bf1e2a56f718@github.com>
Message-ID: <_Jo1JVMWCp8P7A5xfa7g_yYc5Jr2qf1ULjxd219nOCQ=.18923d73-09fb-4d70-8ff6-bb9cc8fcd68b@github.com>

On Fri, 17 Jan 2025 07:41:53 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to make static utility classes final with a private constructor, as they are not meant to be extended.
> 
> This is a small refractor of the generated code.
> 
> TIA

I believe some of the panamization work included manually making these classes `final`, this was meant to prevent the need of manually modifying these files. I opened this PR to see if there is interest in doing this.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/274#issuecomment-2598221589

From pminborg at openjdk.org  Fri Jan 17 12:33:53 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 17 Jan 2025 12:33:53 GMT
Subject: RFR: 7903932: Make private static classes final and have a private
 constructor
In-Reply-To: <NvNwHzwH_tAcc7n1JF0iX5-0jm0-XzE_yomBwFyLt6Q=.132e90ee-6df2-460f-9a5d-bf1e2a56f718@github.com>
References: <NvNwHzwH_tAcc7n1JF0iX5-0jm0-XzE_yomBwFyLt6Q=.132e90ee-6df2-460f-9a5d-bf1e2a56f718@github.com>
Message-ID: <IWZQT1ZzjPYeLrcYN1w46wVsohgaEOdAsNUnUuIEqyM=.b196d3bb-1a18-41eb-a05a-a4586ab45904@github.com>

On Fri, 17 Jan 2025 07:41:53 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to make static utility classes final with a private constructor, as they are not meant to be extended.
> 
> This is a small refractor of the generated code.
> 
> TIA

This looks good to me.

As we have manually made these edits during our panamization efforts, I think this is a convenient change for us. As pointed out above, these classes are private so, making them `final` to adhere to the "utility class pattern" is not a risk.

-------------

Marked as reviewed by pminborg (no project role).

PR Review: https://git.openjdk.org/jextract/pull/274#pullrequestreview-2558903432
PR Comment: https://git.openjdk.org/jextract/pull/274#issuecomment-2598264753

From jvernee at openjdk.org  Fri Jan 17 13:10:51 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 17 Jan 2025 13:10:51 GMT
Subject: RFR: 7903932: Make private static classes final and have a private
 constructor
In-Reply-To: <NvNwHzwH_tAcc7n1JF0iX5-0jm0-XzE_yomBwFyLt6Q=.132e90ee-6df2-460f-9a5d-bf1e2a56f718@github.com>
References: <NvNwHzwH_tAcc7n1JF0iX5-0jm0-XzE_yomBwFyLt6Q=.132e90ee-6df2-460f-9a5d-bf1e2a56f718@github.com>
Message-ID: <POEpr3zPk1MZd9SiDVuChRwChEvB2kEX0QTSwSsVrOY=.d8502cd9-ab0b-45d7-a162-f2c76157f4cd@github.com>

On Fri, 17 Jan 2025 07:41:53 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to make static utility classes final with a private constructor, as they are not meant to be extended.
> 
> This is a small refractor of the generated code.
> 
> TIA

I'm sorry but, the main benefit of this change seems to be making ourselves feel good about following a pattern. I don't think doing this is worth the increased complexity in jextract, and the increased visual clutter in the output.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/274#issuecomment-2598333300

From nbenalla at openjdk.org  Mon Jan 20 10:20:49 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 20 Jan 2025 10:20:49 GMT
Subject: RFR: 7903925: Only the main generated header class should be
 public
In-Reply-To: <NJpBXGlB7-5sSF0RQQsVYsA3FlOpZXSaIhq7jOtEl7k=.bd3df890-617b-4586-aee9-8a12229c4246@github.com>
References: <NJpBXGlB7-5sSF0RQQsVYsA3FlOpZXSaIhq7jOtEl7k=.bd3df890-617b-4586-aee9-8a12229c4246@github.com>
Message-ID: <pFyd8YTmI1tuR6qdR3R252unMzKDEcIXx6TYIuwx-is=.255f96af-1e9e-42e1-9f9b-38ef09b1f7f0@github.com>

On Thu, 16 Jan 2025 12:22:12 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to make the different header classes jextract generates (e.g. foo_h, foo_h_1, foo_h_2, ...) into package-private classes, leaving the main header class (without prefixes) as the only public class.
> 
> While reading the sources, I noticed what seems like small bug in `SourceFileBuilder` introduced in https://github.com/openjdk/jextract/commit/a699148238fad919390d67eeb73805e780a518e8 so I fixed it as part of this patch.
> 
> TIA.

Thanks for the review

-------------

PR Comment: https://git.openjdk.org/jextract/pull/273#issuecomment-2601993063

From duke at openjdk.org  Mon Jan 20 10:20:50 2025
From: duke at openjdk.org (duke)
Date: Mon, 20 Jan 2025 10:20:50 GMT
Subject: RFR: 7903925: Only the main generated header class should be
 public
In-Reply-To: <NJpBXGlB7-5sSF0RQQsVYsA3FlOpZXSaIhq7jOtEl7k=.bd3df890-617b-4586-aee9-8a12229c4246@github.com>
References: <NJpBXGlB7-5sSF0RQQsVYsA3FlOpZXSaIhq7jOtEl7k=.bd3df890-617b-4586-aee9-8a12229c4246@github.com>
Message-ID: <9QsvpQyQCaPnO-2M-v6S3K8QO1VzJeE9iFcYI0C0CKs=.823d1040-7304-4fb6-bdaf-b34c0753385a@github.com>

On Thu, 16 Jan 2025 12:22:12 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to make the different header classes jextract generates (e.g. foo_h, foo_h_1, foo_h_2, ...) into package-private classes, leaving the main header class (without prefixes) as the only public class.
> 
> While reading the sources, I noticed what seems like small bug in `SourceFileBuilder` introduced in https://github.com/openjdk/jextract/commit/a699148238fad919390d67eeb73805e780a518e8 so I fixed it as part of this patch.
> 
> TIA.

@nizarbenalla 
Your change (at version 3c8586af6c9878bca87ef9b5a2f90e7d29603cba) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/273#issuecomment-2601995427

From nbenalla at openjdk.org  Mon Jan 20 11:23:51 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 20 Jan 2025 11:23:51 GMT
Subject: Integrated: 7903925: Only the main generated header class should be
 public
In-Reply-To: <NJpBXGlB7-5sSF0RQQsVYsA3FlOpZXSaIhq7jOtEl7k=.bd3df890-617b-4586-aee9-8a12229c4246@github.com>
References: <NJpBXGlB7-5sSF0RQQsVYsA3FlOpZXSaIhq7jOtEl7k=.bd3df890-617b-4586-aee9-8a12229c4246@github.com>
Message-ID: <e1BRjmKso8C-m3SpjabyC2e_ODsxo4QUtgpnLLh9fwo=.c1e4c186-b8d6-45ea-afc3-3b930498636d@github.com>

On Thu, 16 Jan 2025 12:22:12 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to make the different header classes jextract generates (e.g. foo_h, foo_h_1, foo_h_2, ...) into package-private classes, leaving the main header class (without prefixes) as the only public class.
> 
> While reading the sources, I noticed what seems like small bug in `SourceFileBuilder` introduced in https://github.com/openjdk/jextract/commit/a699148238fad919390d67eeb73805e780a518e8 so I fixed it as part of this patch.
> 
> TIA.

This pull request has now been integrated.

Changeset: 0879fa9f
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/0879fa9faaf1ceb328f64fc32e44e88f24d7c5f8
Stats:     22 lines in 2 files changed: 8 ins; 0 del; 14 mod

7903925: Only the main generated header class should be public

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jextract/pull/273

From duke at openjdk.org  Mon Jan 20 12:26:59 2025
From: duke at openjdk.org (duke)
Date: Mon, 20 Jan 2025 12:26:59 GMT
Subject: RFR: 7903922: Update copyright year for jextract in files where it
 was missed [v7]
In-Reply-To: <wewZZCdwFILiCgD6J7IyCGolRoq6T6A324CndxoUUaY=.da025f60-670b-4244-9098-5f8526685518@github.com>
References: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
 <wewZZCdwFILiCgD6J7IyCGolRoq6T6A324CndxoUUaY=.da025f60-670b-4244-9098-5f8526685518@github.com>
Message-ID: <m-p0EF16mhrrsg9uQ5ZID63ODSAtCIkX8A22ddKQKBI=.5fd5ddc2-c37f-438b-baf1-03143ccc878e@github.com>

On Mon, 13 Jan 2025 18:05:23 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> I have sampled a few files to manually check that this works as intended, I got the list of files changed in a certain year by running.
>> 
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > 2024file.list
>> git log --oneline --since="1/1/2023" --until="31/12/2023" --name-only --pretty=format: | sort -u > 2023file.list
>> 
>> 
>> And then used a script to update the copyright year, I did a random sampling of files to check that it worked as intended.
>> 
>> A few files had their original copyright year changed because I noticed they were added in 2024 instead.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Update copyright of files updated in this PR to 2024"
>   
>   This reverts commit b334ad01fab137f4aa05dd7ebbdf7c12fd79dbd9.

@nizarbenalla 
Your change (at version 624f66e441d78f4d1fea0972a661b39d0aeaca81) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/267#issuecomment-2602290364

From nbenalla at openjdk.org  Mon Jan 20 12:35:50 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 20 Jan 2025 12:35:50 GMT
Subject: RFR: 7903932: Make private static classes final and have a private
 constructor
In-Reply-To: <NvNwHzwH_tAcc7n1JF0iX5-0jm0-XzE_yomBwFyLt6Q=.132e90ee-6df2-460f-9a5d-bf1e2a56f718@github.com>
References: <NvNwHzwH_tAcc7n1JF0iX5-0jm0-XzE_yomBwFyLt6Q=.132e90ee-6df2-460f-9a5d-bf1e2a56f718@github.com>
Message-ID: <HhPPt2_YI-tSj3Qw5giUxcvW4VbyJxqVH39JBxAC9s8=.a223b5e4-757f-4382-a624-b4fa87eb77f9@github.com>

On Fri, 17 Jan 2025 07:41:53 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to make static utility classes final with a private constructor, as they are not meant to be extended.
> 
> This is a small refractor of the generated code.
> 
> TIA

I'm closing this for now, until we get more feedback on whether users tend to make these classes final or not.

It does seem like a reasonable safeguard because users may modify the generated code.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/274#issuecomment-2602310903

From nbenalla at openjdk.org  Mon Jan 20 12:35:50 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 20 Jan 2025 12:35:50 GMT
Subject: Withdrawn: 7903932: Make private static classes final and have a
 private constructor
In-Reply-To: <NvNwHzwH_tAcc7n1JF0iX5-0jm0-XzE_yomBwFyLt6Q=.132e90ee-6df2-460f-9a5d-bf1e2a56f718@github.com>
References: <NvNwHzwH_tAcc7n1JF0iX5-0jm0-XzE_yomBwFyLt6Q=.132e90ee-6df2-460f-9a5d-bf1e2a56f718@github.com>
Message-ID: <OsLzXYS3JB6B6G84i2I-4zdZ7XEOCtp6hqsfNzQNL4U=.236bf563-91eb-4310-a7ff-1c69297ffae6@github.com>

On Fri, 17 Jan 2025 07:41:53 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this patch to make static utility classes final with a private constructor, as they are not meant to be extended.
> 
> This is a small refractor of the generated code.
> 
> TIA

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jextract/pull/274

From nbenalla at openjdk.org  Mon Jan 20 13:22:51 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 20 Jan 2025 13:22:51 GMT
Subject: Integrated: 7903922: Update copyright year for jextract in files where
 it was missed
In-Reply-To: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
References: <NhL_OsFLtzoPbpMYjjxXP3o2qcEdgA5yEbI8DXL6aDI=.df270c62-39b5-460a-b81d-b5ac585677a6@github.com>
Message-ID: <Ul_Ng1F3McROc4lVcZo6Uz1dCHRx70PpkiSdxo6UjV4=.425189fc-b972-4552-96c7-eb1ffdf984f5@github.com>

On Wed, 25 Dec 2024 12:02:14 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> I have sampled a few files to manually check that this works as intended, I got the list of files changed in a certain year by running.
> 
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > 2024file.list
> git log --oneline --since="1/1/2023" --until="31/12/2023" --name-only --pretty=format: | sort -u > 2023file.list
> 
> 
> And then used a script to update the copyright year, I did a random sampling of files to check that it worked as intended.
> 
> A few files had their original copyright year changed because I noticed they were added in 2024 instead.

This pull request has now been integrated.

Changeset: 90a7fc64
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/90a7fc6458d607f44c88b0d50a92a921472eb20d
Stats:     67 lines in 67 files changed: 0 ins; 1 del; 66 mod

7903922: Update copyright year for jextract in files where it was missed

Reviewed-by: mcimadamore, jvernee

-------------

PR: https://git.openjdk.org/jextract/pull/267

From nbenalla at openjdk.org  Tue Jan 21 18:58:53 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 21 Jan 2025 18:58:53 GMT
Subject: RFR: 7903928: update build.gradle to use JDK 23 [v3]
In-Reply-To: <Q2ECR7jW18ayC6lr_w95O4m8cHU9JytYGLNUkMqlXWI=.0566c474-7941-4485-afcc-854c9e9425a1@github.com>
References: <bG0L_6-4sdDc-Wh70u-WJ1dUcHbbZphxxWOIKFVQpEI=.81dcee71-8444-414a-845a-190761081882@github.com>
 <Q2ECR7jW18ayC6lr_w95O4m8cHU9JytYGLNUkMqlXWI=.0566c474-7941-4485-afcc-854c9e9425a1@github.com>
Message-ID: <wfhZi_uqXAlXSt_ekfipazdNjCxJBJKn9HTLMhxiZSw=.7db9d806-c327-4fb9-b4a6-3c57fc8dd343@github.com>

On Thu, 9 Jan 2025 13:35:14 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> We've updated native makefile to use JDK 23 (
>> https://github.com/openjdk/jextract/commit/0b89a462146940a2ec90e34eeb5df3d46d8980d2 )
>> 
>> While build.gradle works & expects jdk 23, it still refers to JDK var as "jdk22_home" and passes --release to be 22. Also jextract version is "22".
>
> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed jdk23_home in test line

This PR has been superseded by #275. Please continue the discussion and review there.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/271#issuecomment-2605509402

From nbenalla at openjdk.org  Tue Jan 21 19:02:21 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 21 Jan 2025 19:02:21 GMT
Subject: RFR: 7903928: update build.gradle to use JDK 23
Message-ID: <s_1596dBbmQJ5yPvrdbsH1L4Zxwy6qdiYAzpo3XjnJA=.ae913405-0b90-4cd7-8095-9d04f809d245@github.com>

We've updated native makefile to use JDK 23 (https://github.com/openjdk/jextract/commit/0b89a462146940a2ec90e34eeb5df3d46d8980d2), build.gradle works & expects jdk 23, it still refers to JDK var as "jdk22_home" and passes --release to be 22. Also jextract version is "22".

The mismatch has caused [some confusion](https://mail.openjdk.org/pipermail/panama-dev/2025-January/020915.html).

This patch to rename references to `jdk22_home` to `jdk_home`, the jextract version has now been bumped to `23`.

This PR has been obtained through a `git merge --squash` of #271.

TIA

-------------

Commit messages:
 - Updates based on review comment in pr/271
 - jextract PR #271

Changes: https://git.openjdk.org/jextract/pull/275/files
  Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=275&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903928
  Stats: 14 lines in 4 files changed: 2 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jextract/pull/275.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/275/head:pull/275

PR: https://git.openjdk.org/jextract/pull/275

From nbenalla at openjdk.org  Tue Jan 21 19:02:21 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 21 Jan 2025 19:02:21 GMT
Subject: RFR: 7903928: update build.gradle to use JDK 23
In-Reply-To: <s_1596dBbmQJ5yPvrdbsH1L4Zxwy6qdiYAzpo3XjnJA=.ae913405-0b90-4cd7-8095-9d04f809d245@github.com>
References: <s_1596dBbmQJ5yPvrdbsH1L4Zxwy6qdiYAzpo3XjnJA=.ae913405-0b90-4cd7-8095-9d04f809d245@github.com>
Message-ID: <AcPmQFlahQco7c2w8JTXDJ7_g45SjPWnjAm3SG7sxBE=.de148c06-5fd5-4038-a8be-1e122f5ae05a@github.com>

On Tue, 21 Jan 2025 18:53:33 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> We've updated native makefile to use JDK 23 (https://github.com/openjdk/jextract/commit/0b89a462146940a2ec90e34eeb5df3d46d8980d2), build.gradle works & expects jdk 23, it still refers to JDK var as "jdk22_home" and passes --release to be 22. Also jextract version is "22".
> 
> The mismatch has caused [some confusion](https://mail.openjdk.org/pipermail/panama-dev/2025-January/020915.html).
> 
> This patch to rename references to `jdk22_home` to `jdk_home`, the jextract version has now been bumped to `23`.
> 
> This PR has been obtained through a `git merge --squash` of #271.
> 
> TIA

README.md line 17:

> 15: ### Building
> 16: 
> 17: `jextract` depends on the [C libclang API](https://clang.llvm.org/doxygen/group__CINDEX.html). To build the jextract sources, the easiest option is to download LLVM binaries for your platform, which can be found [here](https://releases.llvm.org/download.html) (version 13.0.0 is recommended). Both the `jextract` tool and the bindings it generates depend heavily on the [Foreign Function & Memory API](https://openjdk.java.net/jeps/454), so a suitable [jdk 22+ distribution](https://jdk.java.net/23/) is also required.

This is the only change that wasn't based on review comments, I thought the download page should point to JDK 23

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/275#discussion_r1924228123

From liach at openjdk.org  Tue Jan 21 19:06:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 Jan 2025 19:06:55 GMT
Subject: RFR: 7903928: update build.gradle to use JDK 23
In-Reply-To: <AcPmQFlahQco7c2w8JTXDJ7_g45SjPWnjAm3SG7sxBE=.de148c06-5fd5-4038-a8be-1e122f5ae05a@github.com>
References: <s_1596dBbmQJ5yPvrdbsH1L4Zxwy6qdiYAzpo3XjnJA=.ae913405-0b90-4cd7-8095-9d04f809d245@github.com>
 <AcPmQFlahQco7c2w8JTXDJ7_g45SjPWnjAm3SG7sxBE=.de148c06-5fd5-4038-a8be-1e122f5ae05a@github.com>
Message-ID: <dCBIw-sjqnk6cPeFpfi1TD2m8U0SKma58HR9M_XJVys=.f3f888a8-fe11-4aa0-8e13-2de5fe92923b@github.com>

On Tue, 21 Jan 2025 18:57:45 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> We've updated native makefile to use JDK 23 (https://github.com/openjdk/jextract/commit/0b89a462146940a2ec90e34eeb5df3d46d8980d2), build.gradle works & expects jdk 23, it still refers to JDK var as "jdk22_home" and passes --release to be 22. Also jextract version is "22".
>> 
>> The mismatch has caused [some confusion](https://mail.openjdk.org/pipermail/panama-dev/2025-January/020915.html).
>> 
>> This patch to rename references to `jdk22_home` to `jdk_home`, the jextract version has now been bumped to `23`.
>> 
>> This PR has been obtained through a `git merge --squash` of #271.
>> 
>> TIA
>
> README.md line 17:
> 
>> 15: ### Building
>> 16: 
>> 17: `jextract` depends on the [C libclang API](https://clang.llvm.org/doxygen/group__CINDEX.html). To build the jextract sources, the easiest option is to download LLVM binaries for your platform, which can be found [here](https://releases.llvm.org/download.html) (version 13.0.0 is recommended). Both the `jextract` tool and the bindings it generates depend heavily on the [Foreign Function & Memory API](https://openjdk.java.net/jeps/454), so a suitable [jdk 22+ distribution](https://jdk.java.net/23/) is also required.
> 
> This is the only change that wasn't based on review comments, I thought the download page should point to JDK 23

The nominal text should refer to 23, now that gradle passes `--release 23` which is not supported by javac for 22.

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/275#discussion_r1924234713

From liach at openjdk.org  Tue Jan 21 19:06:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 21 Jan 2025 19:06:56 GMT
Subject: RFR: 7903928: update build.gradle to use JDK 23
In-Reply-To: <s_1596dBbmQJ5yPvrdbsH1L4Zxwy6qdiYAzpo3XjnJA=.ae913405-0b90-4cd7-8095-9d04f809d245@github.com>
References: <s_1596dBbmQJ5yPvrdbsH1L4Zxwy6qdiYAzpo3XjnJA=.ae913405-0b90-4cd7-8095-9d04f809d245@github.com>
Message-ID: <Zh1-H2JqIi5u6H_qNf6hOKgyUdPjfWtXonbDXrWHx4A=.cdf9ccd7-93b6-45fa-b8c9-14eefd87705f@github.com>

On Tue, 21 Jan 2025 18:53:33 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> We've updated native makefile to use JDK 23 (https://github.com/openjdk/jextract/commit/0b89a462146940a2ec90e34eeb5df3d46d8980d2), build.gradle works & expects jdk 23, it still refers to JDK var as "jdk22_home" and passes --release to be 22. Also jextract version is "22".
> 
> The mismatch has caused [some confusion](https://mail.openjdk.org/pipermail/panama-dev/2025-January/020915.html).
> 
> This patch to rename references to `jdk22_home` to `jdk_home`, the jextract version has now been bumped to `23`.
> 
> This PR has been obtained through a `git merge --squash` of #271.
> 
> TIA

build.gradle line 63:

> 61: 
> 62: compileJava {
> 63:     options.release = 23

Same as above: with this set, users now must use JDK 23 or higher.

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/275#discussion_r1924235323

From nbenalla at openjdk.org  Tue Jan 21 19:16:31 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 21 Jan 2025 19:16:31 GMT
Subject: RFR: 7903928: update build.gradle to use JDK 23 [v2]
In-Reply-To: <s_1596dBbmQJ5yPvrdbsH1L4Zxwy6qdiYAzpo3XjnJA=.ae913405-0b90-4cd7-8095-9d04f809d245@github.com>
References: <s_1596dBbmQJ5yPvrdbsH1L4Zxwy6qdiYAzpo3XjnJA=.ae913405-0b90-4cd7-8095-9d04f809d245@github.com>
Message-ID: <qNE0UWTL0nUpOrCSQPHm0GxBT5F5g9VvR2d69Di2DnU=.b8d93d26-654e-4a79-9e19-cc763d2eb342@github.com>

> We've updated native makefile to use JDK 23 (https://github.com/openjdk/jextract/commit/0b89a462146940a2ec90e34eeb5df3d46d8980d2), build.gradle works & expects jdk 23, it still refers to JDK var as "jdk22_home" and passes --release to be 22. Also jextract version is "22".
> 
> The mismatch has caused [some confusion](https://mail.openjdk.org/pipermail/panama-dev/2025-January/020915.html).
> 
> This patch to rename references to `jdk22_home` to `jdk_home`, the jextract version has now been bumped to `23`.
> 
> This PR has been obtained through a `git merge --squash` of #271.
> 
> TIA

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - refer to JDK 23
 - Merge remote-tracking branch 'upstream/master' into pull/271
 - Updates based on review comment in pr/271
 - jextract PR #271

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/275/files
  - new: https://git.openjdk.org/jextract/pull/275/files/f0e4b1ab..703b3d8a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=275&range=01
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=275&range=00-01

  Stats: 103 lines in 70 files changed: 8 ins; 1 del; 94 mod
  Patch: https://git.openjdk.org/jextract/pull/275.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/275/head:pull/275

PR: https://git.openjdk.org/jextract/pull/275

From liach at openjdk.org  Wed Jan 22 03:41:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 22 Jan 2025 03:41:48 GMT
Subject: RFR: 7903928: update build.gradle to use JDK 23 [v2]
In-Reply-To: <qNE0UWTL0nUpOrCSQPHm0GxBT5F5g9VvR2d69Di2DnU=.b8d93d26-654e-4a79-9e19-cc763d2eb342@github.com>
References: <s_1596dBbmQJ5yPvrdbsH1L4Zxwy6qdiYAzpo3XjnJA=.ae913405-0b90-4cd7-8095-9d04f809d245@github.com>
 <qNE0UWTL0nUpOrCSQPHm0GxBT5F5g9VvR2d69Di2DnU=.b8d93d26-654e-4a79-9e19-cc763d2eb342@github.com>
Message-ID: <UFxDz9KQDwrRk12iEIgOH46JnzavqTSWTGy6-8H9YIs=.06b93f94-ba02-414b-b14a-6fb78299fbad@github.com>

On Tue, 21 Jan 2025 19:16:31 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> We've updated native makefile to use JDK 23 (https://github.com/openjdk/jextract/commit/0b89a462146940a2ec90e34eeb5df3d46d8980d2), build.gradle works & expects jdk 23, it still refers to JDK var as "jdk22_home" and passes --release to be 22. Also jextract version is "22".
>> 
>> The mismatch has caused [some confusion](https://mail.openjdk.org/pipermail/panama-dev/2025-January/020915.html).
>> 
>> This patch to rename references to `jdk22_home` to `jdk_home`, the jextract version has now been bumped to `23`.
>> 
>> This PR has been obtained through a `git merge --squash` of #271.
>> 
>> TIA
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - refer to JDK 23
>  - Merge remote-tracking branch 'upstream/master' into pull/271
>  - Updates based on review comment in pr/271
>  - jextract PR #271

README.md line 17:

> 15: ### Building
> 16: 
> 17: `jextract` depends on the [C libclang API](https://clang.llvm.org/doxygen/group__CINDEX.html). To build the jextract sources, the easiest option is to download LLVM binaries for your platform, which can be found [here](https://releases.llvm.org/download.html) (version 13.0.0 is recommended). Both the `jextract` tool and the bindings it generates depend heavily on the [Foreign Function & Memory API](https://openjdk.java.net/jeps/454), a suitable [jdk 23 or higher distribution](https://jdk.java.net/23/) is also required.

Suggestion:

`jextract` depends on the [C libclang API](https://clang.llvm.org/doxygen/group__CINDEX.html). To build the jextract sources, the easiest option is to download LLVM binaries for your platform, which can be found [here](https://releases.llvm.org/download.html) (version 13.0.0 is recommended). Both the `jextract` tool and the bindings it generates depend heavily on the [Foreign Function & Memory API](https://openjdk.java.net/jeps/454). A suitable [JDK 23 or higher distribution](https://jdk.java.net/23/) is also required.

nitpick

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/275#discussion_r1924648651

From sundar at openjdk.org  Wed Jan 22 04:33:48 2025
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Wed, 22 Jan 2025 04:33:48 GMT
Subject: RFR: 7903928: update build.gradle to use JDK 23 [v2]
In-Reply-To: <dCBIw-sjqnk6cPeFpfi1TD2m8U0SKma58HR9M_XJVys=.f3f888a8-fe11-4aa0-8e13-2de5fe92923b@github.com>
References: <s_1596dBbmQJ5yPvrdbsH1L4Zxwy6qdiYAzpo3XjnJA=.ae913405-0b90-4cd7-8095-9d04f809d245@github.com>
 <AcPmQFlahQco7c2w8JTXDJ7_g45SjPWnjAm3SG7sxBE=.de148c06-5fd5-4038-a8be-1e122f5ae05a@github.com>
 <dCBIw-sjqnk6cPeFpfi1TD2m8U0SKma58HR9M_XJVys=.f3f888a8-fe11-4aa0-8e13-2de5fe92923b@github.com>
Message-ID: <cw2nxFqvxPhE9mnYzRygWTcCfg_NvNQtmj_edDmcfcg=.caedd15b-ea81-4442-8e0e-f99b39a441c8@github.com>

On Tue, 21 Jan 2025 19:03:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> README.md line 17:
>> 
>>> 15: ### Building
>>> 16: 
>>> 17: `jextract` depends on the [C libclang API](https://clang.llvm.org/doxygen/group__CINDEX.html). To build the jextract sources, the easiest option is to download LLVM binaries for your platform, which can be found [here](https://releases.llvm.org/download.html) (version 13.0.0 is recommended). Both the `jextract` tool and the bindings it generates depend heavily on the [Foreign Function & Memory API](https://openjdk.java.net/jeps/454), so a suitable [jdk 22+ distribution](https://jdk.java.net/23/) is also required.
>> 
>> This is the only change that wasn't based on review comments, I thought the download page should point to JDK 23
>
> The nominal text should refer to 23, now that gradle passes `--release 23` which is not supported by javac for 22.

Correct. jextract generated code uses JDK 23 specific API => jextract from master build can only be used with JDK 23+

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/275#discussion_r1924679441

From sundar at openjdk.org  Wed Jan 22 04:56:49 2025
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Wed, 22 Jan 2025 04:56:49 GMT
Subject: RFR: 7903928: update build.gradle to use JDK 23 [v2]
In-Reply-To: <dCBIw-sjqnk6cPeFpfi1TD2m8U0SKma58HR9M_XJVys=.f3f888a8-fe11-4aa0-8e13-2de5fe92923b@github.com>
References: <s_1596dBbmQJ5yPvrdbsH1L4Zxwy6qdiYAzpo3XjnJA=.ae913405-0b90-4cd7-8095-9d04f809d245@github.com>
 <AcPmQFlahQco7c2w8JTXDJ7_g45SjPWnjAm3SG7sxBE=.de148c06-5fd5-4038-a8be-1e122f5ae05a@github.com>
 <dCBIw-sjqnk6cPeFpfi1TD2m8U0SKma58HR9M_XJVys=.f3f888a8-fe11-4aa0-8e13-2de5fe92923b@github.com>
Message-ID: <i9vKNLkJL4lGThoac_AtdNb1-CNHT5rGpwTrWTA2ORo=.70c064da-f5d1-41a0-89f9-2e7f44991aca@github.com>

On Tue, 21 Jan 2025 19:03:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> README.md line 17:
>> 
>>> 15: ### Building
>>> 16: 
>>> 17: `jextract` depends on the [C libclang API](https://clang.llvm.org/doxygen/group__CINDEX.html). To build the jextract sources, the easiest option is to download LLVM binaries for your platform, which can be found [here](https://releases.llvm.org/download.html) (version 13.0.0 is recommended). Both the `jextract` tool and the bindings it generates depend heavily on the [Foreign Function & Memory API](https://openjdk.java.net/jeps/454), so a suitable [jdk 22+ distribution](https://jdk.java.net/23/) is also required.
>> 
>> This is the only change that wasn't based on review comments, I thought the download page should point to JDK 23
>
> The nominal text should refer to 23, now that gradle passes `--release 23` which is not supported by javac for 22.

Yes, the jextract generated code uses JDK 23 specific API and hence jextract tests fail when jextract repo is built with JDK 22.  

We should stick using/mentioning JDK 23+ everywhere in the "master" branch.

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/275#discussion_r1924692840

From sundar at openjdk.org  Wed Jan 22 04:59:49 2025
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Wed, 22 Jan 2025 04:59:49 GMT
Subject: RFR: 7903928: update build.gradle to use JDK 23 [v2]
In-Reply-To: <qNE0UWTL0nUpOrCSQPHm0GxBT5F5g9VvR2d69Di2DnU=.b8d93d26-654e-4a79-9e19-cc763d2eb342@github.com>
References: <s_1596dBbmQJ5yPvrdbsH1L4Zxwy6qdiYAzpo3XjnJA=.ae913405-0b90-4cd7-8095-9d04f809d245@github.com>
 <qNE0UWTL0nUpOrCSQPHm0GxBT5F5g9VvR2d69Di2DnU=.b8d93d26-654e-4a79-9e19-cc763d2eb342@github.com>
Message-ID: <Hj49Ax55E5IFJNRpT1B8rspdX2-RyOmYZUmex0U5-bg=.f397608e-c366-4be9-88df-c172f49f315b@github.com>

On Tue, 21 Jan 2025 19:16:31 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> We've updated native makefile to use JDK 23 (https://github.com/openjdk/jextract/commit/0b89a462146940a2ec90e34eeb5df3d46d8980d2), build.gradle works & expects jdk 23, it still refers to JDK var as "jdk22_home" and passes --release to be 22. Also jextract version is "22".
>> 
>> The mismatch has caused [some confusion](https://mail.openjdk.org/pipermail/panama-dev/2025-January/020915.html).
>> 
>> This patch to rename references to `jdk22_home` to `jdk_home`, the jextract version has now been bumped to `23`.
>> 
>> This PR has been obtained through a `git merge --squash` of #271.
>> 
>> TIA
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - refer to JDK 23
>  - Merge remote-tracking branch 'upstream/master' into pull/271
>  - Updates based on review comment in pr/271
>  - jextract PR #271

LGTM

-------------

Marked as reviewed by sundar (Committer).

PR Review: https://git.openjdk.org/jextract/pull/275#pullrequestreview-2566190927

From nbenalla at openjdk.org  Wed Jan 22 11:33:26 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 22 Jan 2025 11:33:26 GMT
Subject: RFR: 7903928: update build.gradle to use JDK 23 [v3]
In-Reply-To: <s_1596dBbmQJ5yPvrdbsH1L4Zxwy6qdiYAzpo3XjnJA=.ae913405-0b90-4cd7-8095-9d04f809d245@github.com>
References: <s_1596dBbmQJ5yPvrdbsH1L4Zxwy6qdiYAzpo3XjnJA=.ae913405-0b90-4cd7-8095-9d04f809d245@github.com>
Message-ID: <jGKHe0FsRvfxW08nlEi4YoG710pRUnvc7pIj6axe7MY=.b3229dcb-cbb5-4b84-bf6e-f250893b0e84@github.com>

> We've updated native makefile to use JDK 23 (https://github.com/openjdk/jextract/commit/0b89a462146940a2ec90e34eeb5df3d46d8980d2), build.gradle works & expects jdk 23, it still refers to JDK var as "jdk22_home" and passes --release to be 22. Also jextract version is "22".
> 
> The mismatch has caused [some confusion](https://mail.openjdk.org/pipermail/panama-dev/2025-January/020915.html).
> 
> This patch to rename references to `jdk22_home` to `jdk_home`, the jextract version has now been bumped to `23`.
> 
> This PR has been obtained through a `git merge --squash` of #271.
> 
> TIA

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  nit
  
  Co-authored-by: Chen Liang <liach at openjdk.org>

-------------

Changes:
  - all: https://git.openjdk.org/jextract/pull/275/files
  - new: https://git.openjdk.org/jextract/pull/275/files/703b3d8a..259c417a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=275&range=02
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=275&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jextract/pull/275.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/275/head:pull/275

PR: https://git.openjdk.org/jextract/pull/275

From nbenalla at openjdk.org  Wed Jan 22 11:52:55 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 22 Jan 2025 11:52:55 GMT
Subject: RFR: 7903928: update build.gradle to use JDK 23 [v3]
In-Reply-To: <jGKHe0FsRvfxW08nlEi4YoG710pRUnvc7pIj6axe7MY=.b3229dcb-cbb5-4b84-bf6e-f250893b0e84@github.com>
References: <s_1596dBbmQJ5yPvrdbsH1L4Zxwy6qdiYAzpo3XjnJA=.ae913405-0b90-4cd7-8095-9d04f809d245@github.com>
 <jGKHe0FsRvfxW08nlEi4YoG710pRUnvc7pIj6axe7MY=.b3229dcb-cbb5-4b84-bf6e-f250893b0e84@github.com>
Message-ID: <WJcx8tLS0P46JJ8lmaQPmQBsnI0FmQZ7KVbAp8rP7vE=.18add83f-932c-4f87-bccf-c8b9f4711c1b@github.com>

On Wed, 22 Jan 2025 11:33:26 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> We've updated native makefile to use JDK 23 (https://github.com/openjdk/jextract/commit/0b89a462146940a2ec90e34eeb5df3d46d8980d2), build.gradle works & expects jdk 23, it still refers to JDK var as "jdk22_home" and passes --release to be 22. Also jextract version is "22".
>> 
>> The mismatch has caused [some confusion](https://mail.openjdk.org/pipermail/panama-dev/2025-January/020915.html).
>> 
>> This patch to rename references to `jdk22_home` to `jdk_home`, the jextract version has now been bumped to `23`.
>> 
>> This PR has been obtained through a `git merge --squash` of #271.
>> 
>> TIA
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   nit
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

Thanks for the review Sundar, I committed a trivial change after it.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/275#issuecomment-2607036573

From duke at openjdk.org  Wed Jan 22 11:52:56 2025
From: duke at openjdk.org (duke)
Date: Wed, 22 Jan 2025 11:52:56 GMT
Subject: RFR: 7903928: update build.gradle to use JDK 23 [v3]
In-Reply-To: <jGKHe0FsRvfxW08nlEi4YoG710pRUnvc7pIj6axe7MY=.b3229dcb-cbb5-4b84-bf6e-f250893b0e84@github.com>
References: <s_1596dBbmQJ5yPvrdbsH1L4Zxwy6qdiYAzpo3XjnJA=.ae913405-0b90-4cd7-8095-9d04f809d245@github.com>
 <jGKHe0FsRvfxW08nlEi4YoG710pRUnvc7pIj6axe7MY=.b3229dcb-cbb5-4b84-bf6e-f250893b0e84@github.com>
Message-ID: <HQAIGat_m2KGRx6PpX0ZrflxyGEb0B_5An6UPYxIFSA=.4dbb9c43-584f-4549-841b-563a08e5dac8@github.com>

On Wed, 22 Jan 2025 11:33:26 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> We've updated native makefile to use JDK 23 (https://github.com/openjdk/jextract/commit/0b89a462146940a2ec90e34eeb5df3d46d8980d2), build.gradle works & expects jdk 23, it still refers to JDK var as "jdk22_home" and passes --release to be 22. Also jextract version is "22".
>> 
>> The mismatch has caused [some confusion](https://mail.openjdk.org/pipermail/panama-dev/2025-January/020915.html).
>> 
>> This patch to rename references to `jdk22_home` to `jdk_home`, the jextract version has now been bumped to `23`.
>> 
>> This PR has been obtained through a `git merge --squash` of #271.
>> 
>> TIA
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   nit
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

@nizarbenalla 
Your change (at version 259c417a54e752e80c570b0df8ea1d491f307184) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jextract/pull/275#issuecomment-2607037408

From nbenalla at openjdk.org  Wed Jan 22 16:54:07 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 22 Jan 2025 16:54:07 GMT
Subject: Integrated: 7903928: update build.gradle to use JDK 23
In-Reply-To: <s_1596dBbmQJ5yPvrdbsH1L4Zxwy6qdiYAzpo3XjnJA=.ae913405-0b90-4cd7-8095-9d04f809d245@github.com>
References: <s_1596dBbmQJ5yPvrdbsH1L4Zxwy6qdiYAzpo3XjnJA=.ae913405-0b90-4cd7-8095-9d04f809d245@github.com>
Message-ID: <FFcCJQAmR3nXNzzc1aW51Mxk0nPXi0Lb-44E08vNFq8=.f3f82fd9-6e6e-4306-a374-ff05fe24e577@github.com>

On Tue, 21 Jan 2025 18:53:33 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> We've updated native makefile to use JDK 23 (https://github.com/openjdk/jextract/commit/0b89a462146940a2ec90e34eeb5df3d46d8980d2), build.gradle works & expects jdk 23, it still refers to JDK var as "jdk22_home" and passes --release to be 22. Also jextract version is "22".
> 
> The mismatch has caused [some confusion](https://mail.openjdk.org/pipermail/panama-dev/2025-January/020915.html).
> 
> This patch to rename references to `jdk22_home` to `jdk_home`, the jextract version has now been bumped to `23`.
> 
> This PR has been obtained through a `git merge --squash` of #271.
> 
> TIA

This pull request has now been integrated.

Changeset: 7ed79ecd
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/7ed79ecdf678db804f40b3494b6f1dafa760c808
Stats:     14 lines in 4 files changed: 2 ins; 0 del; 12 mod

7903928: update build.gradle to use JDK 23

Co-authored-by: Athijegannathan Sundararajan <sundar at openjdk.org>
Reviewed-by: sundar

-------------

PR: https://git.openjdk.org/jextract/pull/275

From nlisker at gmail.com  Sun Jan 26 07:51:20 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Sun, 26 Jan 2025 09:51:20 +0200
Subject: Javadoc for API
Message-ID: <CA+0ynh_ybzVdB1UnxjC7Lc1gGy3pVV6+++av-ojXMej5G7_85Q@mail.gmail.com>

Hi,

There are several public methods the JextractTool exposes. Please javadoc
to these methods so tool users will know what they do and how to use them.

Thanks,
- Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250126/64f939dd/attachment-0001.htm>

From nlisker at gmail.com  Sun Jan 26 09:18:27 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Sun, 26 Jan 2025 11:18:27 +0200
Subject: Detailed version info
Message-ID: <CA+0ynh9Hhioa-z=GPOWS8OddD1sq_NgzvAF6yNGR7opuHiAV9g@mail.gmail.com>

Hi,

The output of the --version parameter looks like this:
jextract 22
JDK version 22+35-2369
LibClang version clang version 13.0.0

Is it possible to include a more detailed version of jextract, like the JDK
does? e.g., the current build is Build 22-jextract+6-47.

Also, is it possible to add a programmatic API to get the --version info
such as a method on JextractTool? Java has a Runtime.Version class that is
returned from Runtime#version. Maybe something like that is possible?

Thanks,
Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250126/cec5c83f/attachment.htm>

From jorn.vernee at oracle.com  Tue Jan 28 11:56:14 2025
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Tue, 28 Jan 2025 12:56:14 +0100
Subject: Detailed version info
In-Reply-To: <CA+0ynh9Hhioa-z=GPOWS8OddD1sq_NgzvAF6yNGR7opuHiAV9g@mail.gmail.com>
References: <CA+0ynh9Hhioa-z=GPOWS8OddD1sq_NgzvAF6yNGR7opuHiAV9g@mail.gmail.com>
Message-ID: <83fff2bb-2e0e-45ac-8a63-7c65d17bddad@oracle.com>

Hey Nir,

The version format for jextract was modeled after what we do for other 
JDK tools. I think this works well when a tool is included in the JDK, 
but for jextract we might also have 'minor' releases that target the 
same major java version, but include extra fixes.

Having a minor version, or including the build number in the version 
string, like you suggest, doesn't seem like a bad idea to help 
distinguish between different versions of jextract that target the same 
java version. I've filed: https://bugs.openjdk.org/browse/CODETOOLS-7903941

Jorn

On 26-1-2025 10:18, Nir Lisker wrote:
> Hi,
>
> The output of the --version parameter looks like this:
> jextract 22
> JDK version 22+35-2369
> LibClang version clang version 13.0.0
>
> Is it possible to include a more detailed version of jextract, like 
> the JDK does? e.g., the current build is Build 22-jextract+6-47.
>
> Also, is it possible to add a programmatic?API to get the --version 
> info such as a method on JextractTool? Java has a Runtime.Version 
> class that is returned from Runtime#version. Maybe something like that 
> is possible?
>
> Thanks,
> Nir

From jorn.vernee at oracle.com  Tue Jan 28 12:28:29 2025
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Tue, 28 Jan 2025 13:28:29 +0100
Subject: Javadoc for API
In-Reply-To: <CA+0ynh_ybzVdB1UnxjC7Lc1gGy3pVV6+++av-ojXMej5G7_85Q@mail.gmail.com>
References: <CA+0ynh_ybzVdB1UnxjC7Lc1gGy3pVV6+++av-ojXMej5G7_85Q@mail.gmail.com>
Message-ID: <4a3c5f6a-dc47-4118-b72f-696fd2ba30e8@oracle.com>

Hey Nir,

The jextract API has been neglected for a while (as you've found). 
Initially it was a way of avoiding adding many flags to jextract, to do 
things like filtering, renaming, and other things. The idea being that 
if users wanted more control of what jextract did, they could use the 
API. But, now it seems like we're moving in that direction any way, with 
the JSON based configuration: 
https://bugs.openjdk.org/browse/CODETOOLS-7903788

I think we need to re-asses which use cases the jextract API addresses, 
and whether using jextract through the ToolProvider interface, with the 
extended configuration options, is also an option.

IIRC your use case is filtering the jextract output, right? Do you think 
it would be possible to use the ToolProvider interface with a 
combination of --dump-includes, and automatically generated 
--include-XXX flags, to achieve the same level of functionality?

Jorn

On 26-1-2025 08:51, Nir Lisker wrote:
> Hi,
>
> There are several public methods the JextractTool?exposes. Please 
> javadoc to these methods so tool users will know what they do and how 
> to use them.
>
> Thanks,
> - Nir

From nlisker at gmail.com  Tue Jan 28 14:12:06 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 28 Jan 2025 16:12:06 +0200
Subject: Javadoc for API
In-Reply-To: <4a3c5f6a-dc47-4118-b72f-696fd2ba30e8@oracle.com>
References: <CA+0ynh_ybzVdB1UnxjC7Lc1gGy3pVV6+++av-ojXMej5G7_85Q@mail.gmail.com>
 <4a3c5f6a-dc47-4118-b72f-696fd2ba30e8@oracle.com>
Message-ID: <CA+0ynh9nwiaMA5Abg67tAJzJyZJwGC_uWqscOh_pjQvg9cF19A@mail.gmail.com>

I use
JextractTool.parse(List<String> arg0, String... arg1)
to inspect given header files. Then I use
ToolProvider.run(PrintStream out, PrintStream err, String... args)
which is not Jextract-specific to run the tool with the user's
configuration. There is no need for a dump.

I want to release an alpha soon so you'll be able to see how it works.

On Tue, Jan 28, 2025 at 2:28?PM Jorn Vernee <jorn.vernee at oracle.com> wrote:

> Hey Nir,
>
> The jextract API has been neglected for a while (as you've found).
> Initially it was a way of avoiding adding many flags to jextract, to do
> things like filtering, renaming, and other things. The idea being that
> if users wanted more control of what jextract did, they could use the
> API. But, now it seems like we're moving in that direction any way, with
> the JSON based configuration:
> https://bugs.openjdk.org/browse/CODETOOLS-7903788
>
> I think we need to re-asses which use cases the jextract API addresses,
> and whether using jextract through the ToolProvider interface, with the
> extended configuration options, is also an option.
>
> IIRC your use case is filtering the jextract output, right? Do you think
> it would be possible to use the ToolProvider interface with a
> combination of --dump-includes, and automatically generated
> --include-XXX flags, to achieve the same level of functionality?
>
> Jorn
>
> On 26-1-2025 08:51, Nir Lisker wrote:
> > Hi,
> >
> > There are several public methods the JextractTool exposes. Please
> > javadoc to these methods so tool users will know what they do and how
> > to use them.
> >
> > Thanks,
> > - Nir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250128/c66266fd/attachment.htm>

From jorn.vernee at oracle.com  Tue Jan 28 15:06:02 2025
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Tue, 28 Jan 2025 16:06:02 +0100
Subject: [External] : Re: Javadoc for API
In-Reply-To: <CA+0ynh9nwiaMA5Abg67tAJzJyZJwGC_uWqscOh_pjQvg9cF19A@mail.gmail.com>
References: <CA+0ynh_ybzVdB1UnxjC7Lc1gGy3pVV6+++av-ojXMej5G7_85Q@mail.gmail.com>
 <4a3c5f6a-dc47-4118-b72f-696fd2ba30e8@oracle.com>
 <CA+0ynh9nwiaMA5Abg67tAJzJyZJwGC_uWqscOh_pjQvg9cF19A@mail.gmail.com>
Message-ID: <4bc5ee46-6a30-48c9-ad4d-fdb0abefb99c@oracle.com>

 > There is no need for a dump.

But, do you think you could do the things you're doing, using 
JextractTool::parse, by using --dump-includes instead?

I'm trying to assess if we even need the API at all, or if we can just 
have the ToolProvider.

Jorn

On 28-1-2025 15:12, Nir Lisker wrote:
> I use
> JextractTool.parse(List<String> arg0, String... arg1)
> to inspect given header files. Then I use
> ToolProvider.run(PrintStream out, PrintStream err, String... args)
> which is not Jextract-specific to run the tool with the user's 
> configuration. There is no need for a dump.
>
> I want to release an alpha soon so you'll be able?to see how it works.
>
> On Tue, Jan 28, 2025 at 2:28?PM Jorn Vernee <jorn.vernee at oracle.com> 
> wrote:
>
>     Hey Nir,
>
>     The jextract API has been neglected for a while (as you've found).
>     Initially it was a way of avoiding adding many flags to jextract,
>     to do
>     things like filtering, renaming, and other things. The idea being
>     that
>     if users wanted more control of what jextract did, they could use the
>     API. But, now it seems like we're moving in that direction any
>     way, with
>     the JSON based configuration:
>     https://bugs.openjdk.org/browse/CODETOOLS-7903788
>
>     I think we need to re-asses which use cases the jextract API
>     addresses,
>     and whether using jextract through the ToolProvider interface,
>     with the
>     extended configuration options, is also an option.
>
>     IIRC your use case is filtering the jextract output, right? Do you
>     think
>     it would be possible to use the ToolProvider interface with a
>     combination of --dump-includes, and automatically generated
>     --include-XXX flags, to achieve the same level of functionality?
>
>     Jorn
>
>     On 26-1-2025 08:51, Nir Lisker wrote:
>     > Hi,
>     >
>     > There are several public methods the JextractTool?exposes. Please
>     > javadoc to these methods so tool users will know what they do
>     and how
>     > to use them.
>     >
>     > Thanks,
>     > - Nir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250128/2a2f76a8/attachment.htm>

From nlisker at gmail.com  Thu Jan 30 13:06:04 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Thu, 30 Jan 2025 15:06:04 +0200
Subject: [External] : Re: Javadoc for API
In-Reply-To: <4bc5ee46-6a30-48c9-ad4d-fdb0abefb99c@oracle.com>
References: <CA+0ynh_ybzVdB1UnxjC7Lc1gGy3pVV6+++av-ojXMej5G7_85Q@mail.gmail.com>
 <4a3c5f6a-dc47-4118-b72f-696fd2ba30e8@oracle.com>
 <CA+0ynh9nwiaMA5Abg67tAJzJyZJwGC_uWqscOh_pjQvg9cF19A@mail.gmail.com>
 <4bc5ee46-6a30-48c9-ad4d-fdb0abefb99c@oracle.com>
Message-ID: <CA+0ynh_vCCgHMURMYYQ8g5oFnC8=Jtna-rbFQXxx39h-M6Ktuw@mail.gmail.com>

It's probably possible to do, but looks roundabout.

Here is my setup in more detail:
1. A header is given to the application. It calls 'parse' on it to get all
the Declarations.
2. The user can configure which declarations to include in the GUI, and
also the other options such as class name, macros, output dir etc.
3. The 'run' method is called with the arguments generated from the
configuration.

It's all in-memory.

With --dump-includes:
1. A header is given to the application. A JSON file is created.
2. The file is read and parsed to produce the Declarations. Configuring a
JSON parser is already a lot of work for polymorphic sybtyping (all the
types of Declarations). Will jextract provide a parser? What is the format?
Is it stable?
3. Is 2 above.
4. Is 3 above.

So we complicated things by creating a file from which we need to read the
data that would otherwise be given to us directly by 'parse'. At least this
is my understanding.

Speaking of 'parse', I notice that it doesn't throw an exception on a
missing '#include <header.h>' as it used to. Now I only see a printed
error. Has this changed? Is there a way to capture this error somehow so
that the user knows something went wrong?

On Tue, Jan 28, 2025 at 5:06?PM Jorn Vernee <jorn.vernee at oracle.com> wrote:

> > There is no need for a dump.
>
> But, do you think you could do the things you're doing, using
> JextractTool::parse, by using --dump-includes instead?
>
> I'm trying to assess if we even need the API at all, or if we can just
> have the ToolProvider.
>
> Jorn
> On 28-1-2025 15:12, Nir Lisker wrote:
>
> I use
> JextractTool.parse(List<String> arg0, String... arg1)
> to inspect given header files. Then I use
> ToolProvider.run(PrintStream out, PrintStream err, String... args)
> which is not Jextract-specific to run the tool with the user's
> configuration. There is no need for a dump.
>
> I want to release an alpha soon so you'll be able to see how it works.
>
> On Tue, Jan 28, 2025 at 2:28?PM Jorn Vernee <jorn.vernee at oracle.com>
> wrote:
>
>> Hey Nir,
>>
>> The jextract API has been neglected for a while (as you've found).
>> Initially it was a way of avoiding adding many flags to jextract, to do
>> things like filtering, renaming, and other things. The idea being that
>> if users wanted more control of what jextract did, they could use the
>> API. But, now it seems like we're moving in that direction any way, with
>> the JSON based configuration:
>> https://bugs.openjdk.org/browse/CODETOOLS-7903788
>>
>> I think we need to re-asses which use cases the jextract API addresses,
>> and whether using jextract through the ToolProvider interface, with the
>> extended configuration options, is also an option.
>>
>> IIRC your use case is filtering the jextract output, right? Do you think
>> it would be possible to use the ToolProvider interface with a
>> combination of --dump-includes, and automatically generated
>> --include-XXX flags, to achieve the same level of functionality?
>>
>> Jorn
>>
>> On 26-1-2025 08:51, Nir Lisker wrote:
>> > Hi,
>> >
>> > There are several public methods the JextractTool exposes. Please
>> > javadoc to these methods so tool users will know what they do and how
>> > to use them.
>> >
>> > Thanks,
>> > - Nir
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250130/5a5a165a/attachment-0001.htm>

From jorn.vernee at oracle.com  Thu Jan 30 18:20:30 2025
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Thu, 30 Jan 2025 19:20:30 +0100
Subject: [External] : Re: Javadoc for API
In-Reply-To: <CA+0ynh_vCCgHMURMYYQ8g5oFnC8=Jtna-rbFQXxx39h-M6Ktuw@mail.gmail.com>
References: <CA+0ynh_ybzVdB1UnxjC7Lc1gGy3pVV6+++av-ojXMej5G7_85Q@mail.gmail.com>
 <4a3c5f6a-dc47-4118-b72f-696fd2ba30e8@oracle.com>
 <CA+0ynh9nwiaMA5Abg67tAJzJyZJwGC_uWqscOh_pjQvg9cF19A@mail.gmail.com>
 <4bc5ee46-6a30-48c9-ad4d-fdb0abefb99c@oracle.com>
 <CA+0ynh_vCCgHMURMYYQ8g5oFnC8=Jtna-rbFQXxx39h-M6Ktuw@mail.gmail.com>
Message-ID: <01d79af3-0e3e-4a70-b78d-d44724958c73@oracle.com>

Note that --dump-includes already exists, and generates a flat list of 
`--include-XXX` options that can be passed back to jextract (not JSON). 
You would need to parse these options manually. I think the format would 
be relatively stable, only needing to change if we change the command 
line options.

 > Speaking of 'parse', I notice that it doesn't throw an exception on a 
missing '#include <header.h>' as it used to. Now I only see a printed 
error. Has this changed? Is there a way to capture this error somehow so 
that the user knows something went wrong?

Yes, this changed as part of: https://github.com/openjdk/jextract/pull/255

It looks like the Logger class that was added is not part of the public 
API, so right now I don't think there's a way to capture those errors 
aside from capturing and parsing them from the output.

Jorn

On 30-1-2025 14:06, Nir Lisker wrote:
> It's probably possible to do, but looks roundabout.
>
> Here is my setup in more?detail:
> 1. A header is given to the application. It calls 'parse' on it to get 
> all the Declarations.
> 2. The user can configure which declarations to include in the GUI, 
> and also the other options such as class name, macros, output dir etc.
> 3. The 'run' method is called with the arguments generated from the 
> configuration.
>
> It's all in-memory.
>
> With --dump-includes:
> 1. A header is given to the application. A JSON file is created.
> 2. The file is read and parsed to produce the Declarations. 
> Configuring a JSON parser is already a lot of work for?polymorphic 
> sybtyping?(all the types of Declarations). Will jextract provide a 
> parser? What is the format? Is it stable?
> 3. Is 2 above.
> 4. Is 3 above.
>
> So we complicated?things by creating a file from which we need to read 
> the data that would otherwise be given to us directly by 'parse'. At 
> least this is my understanding.
>
> Speaking of 'parse', I notice that it doesn't throw an exception on a 
> missing '#include <header.h>' as it used to. Now I only see a printed 
> error. Has this changed? Is there a way to capture this error somehow 
> so that the user knows something went wrong?
>
> On Tue, Jan 28, 2025 at 5:06?PM Jorn Vernee <jorn.vernee at oracle.com> 
> wrote:
>
>     > There is no need for a dump.
>
>     But, do you think you could do the things you're doing, using
>     JextractTool::parse, by using --dump-includes instead?
>
>     I'm trying to assess if we even need the API at all, or if we can
>     just have the ToolProvider.
>
>     Jorn
>
>     On 28-1-2025 15:12, Nir Lisker wrote:
>>     I use
>>     JextractTool.parse(List<String> arg0, String... arg1)
>>     to inspect given header files. Then I use
>>     ToolProvider.run(PrintStream out, PrintStream err, String... args)
>>     which is not Jextract-specific to run the tool with the user's
>>     configuration. There is no need for a dump.
>>
>>     I want to release an alpha soon so you'll be able?to see how it
>>     works.
>>
>>     On Tue, Jan 28, 2025 at 2:28?PM Jorn Vernee
>>     <jorn.vernee at oracle.com> wrote:
>>
>>         Hey Nir,
>>
>>         The jextract API has been neglected for a while (as you've
>>         found).
>>         Initially it was a way of avoiding adding many flags to
>>         jextract, to do
>>         things like filtering, renaming, and other things. The idea
>>         being that
>>         if users wanted more control of what jextract did, they could
>>         use the
>>         API. But, now it seems like we're moving in that direction
>>         any way, with
>>         the JSON based configuration:
>>         https://bugs.openjdk.org/browse/CODETOOLS-7903788
>>
>>         I think we need to re-asses which use cases the jextract API
>>         addresses,
>>         and whether using jextract through the ToolProvider
>>         interface, with the
>>         extended configuration options, is also an option.
>>
>>         IIRC your use case is filtering the jextract output, right?
>>         Do you think
>>         it would be possible to use the ToolProvider interface with a
>>         combination of --dump-includes, and automatically generated
>>         --include-XXX flags, to achieve the same level of functionality?
>>
>>         Jorn
>>
>>         On 26-1-2025 08:51, Nir Lisker wrote:
>>         > Hi,
>>         >
>>         > There are several public methods the JextractTool?exposes.
>>         Please
>>         > javadoc to these methods so tool users will know what they
>>         do and how
>>         > to use them.
>>         >
>>         > Thanks,
>>         > - Nir
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250130/9942c47d/attachment.htm>

From nlisker at gmail.com  Thu Jan 30 18:48:20 2025
From: nlisker at gmail.com (Nir Lisker)
Date: Thu, 30 Jan 2025 20:48:20 +0200
Subject: [External] : Re: Javadoc for API
In-Reply-To: <01d79af3-0e3e-4a70-b78d-d44724958c73@oracle.com>
References: <CA+0ynh_ybzVdB1UnxjC7Lc1gGy3pVV6+++av-ojXMej5G7_85Q@mail.gmail.com>
 <4a3c5f6a-dc47-4118-b72f-696fd2ba30e8@oracle.com>
 <CA+0ynh9nwiaMA5Abg67tAJzJyZJwGC_uWqscOh_pjQvg9cF19A@mail.gmail.com>
 <4bc5ee46-6a30-48c9-ad4d-fdb0abefb99c@oracle.com>
 <CA+0ynh_vCCgHMURMYYQ8g5oFnC8=Jtna-rbFQXxx39h-M6Ktuw@mail.gmail.com>
 <01d79af3-0e3e-4a70-b78d-d44724958c73@oracle.com>
Message-ID: <CA+0ynh9A+TNSnVj14kgDCGUt2SdyazbCAJeyByjXqwQfFemhdA@mail.gmail.com>

>
> Note that --dump-includes already exists, and generates a flat list of
> `--include-XXX` options that can be passed back to jextract (not JSON).


I saw that, but these are just string names. They don't contain all the
info in a Declaration, which can be useful to the user.

And it still adds extra steps. When jextract receives a head, it generates
a list of Declarations. Now, instead of directly sending it back, it maps
them to strings (in whatever format) and writes them to a file; then an
application needs to read that file and parse the strings back to
Declarations. But we already had these Declarations to begin with.
The way I see it, jextract has 2 functions: inspect a header(s), and
generate bindings for a header(s). While ToolProvier#run covers these, it
requires extra hoops to jump through, such as the above parsing and also
reading messages from the standard streams. Removing the exception  on a
parsing error was enough to disable one of the features of the app that
informs the user that an include dir is missing.

If you're interested, I can give you and anyone else in the jextract team
access to the repo and you can try it out, although it's still in beta. I
intend to make it public anyway when I can prove it works on non-Windows
machines.

On Thu, Jan 30, 2025 at 8:20?PM Jorn Vernee <jorn.vernee at oracle.com> wrote:

> Note that --dump-includes already exists, and generates a flat list of
> `--include-XXX` options that can be passed back to jextract (not JSON). You
> would need to parse these options manually. I think the format would be
> relatively stable, only needing to change if we change the command line
> options.
>
> > Speaking of 'parse', I notice that it doesn't throw an exception on a
> missing '#include <header.h>' as it used to. Now I only see a printed
> error. Has this changed? Is there a way to capture this error somehow so
> that the user knows something went wrong?
>
> Yes, this changed as part of: https://github.com/openjdk/jextract/pull/255
>
> It looks like the Logger class that was added is not part of the public
> API, so right now I don't think there's a way to capture those errors aside
> from capturing and parsing them from the output.
>
> Jorn
> On 30-1-2025 14:06, Nir Lisker wrote:
>
> It's probably possible to do, but looks roundabout.
>
> Here is my setup in more detail:
> 1. A header is given to the application. It calls 'parse' on it to get all
> the Declarations.
> 2. The user can configure which declarations to include in the GUI, and
> also the other options such as class name, macros, output dir etc.
> 3. The 'run' method is called with the arguments generated from the
> configuration.
>
> It's all in-memory.
>
> With --dump-includes:
> 1. A header is given to the application. A JSON file is created.
> 2. The file is read and parsed to produce the Declarations. Configuring a
> JSON parser is already a lot of work for polymorphic sybtyping (all the
> types of Declarations). Will jextract provide a parser? What is the format?
> Is it stable?
> 3. Is 2 above.
> 4. Is 3 above.
>
> So we complicated things by creating a file from which we need to read the
> data that would otherwise be given to us directly by 'parse'. At least this
> is my understanding.
>
> Speaking of 'parse', I notice that it doesn't throw an exception on a
> missing '#include <header.h>' as it used to. Now I only see a printed
> error. Has this changed? Is there a way to capture this error somehow so
> that the user knows something went wrong?
>
> On Tue, Jan 28, 2025 at 5:06?PM Jorn Vernee <jorn.vernee at oracle.com>
> wrote:
>
>> > There is no need for a dump.
>>
>> But, do you think you could do the things you're doing, using
>> JextractTool::parse, by using --dump-includes instead?
>>
>> I'm trying to assess if we even need the API at all, or if we can just
>> have the ToolProvider.
>>
>> Jorn
>> On 28-1-2025 15:12, Nir Lisker wrote:
>>
>> I use
>> JextractTool.parse(List<String> arg0, String... arg1)
>> to inspect given header files. Then I use
>> ToolProvider.run(PrintStream out, PrintStream err, String... args)
>> which is not Jextract-specific to run the tool with the user's
>> configuration. There is no need for a dump.
>>
>> I want to release an alpha soon so you'll be able to see how it works.
>>
>> On Tue, Jan 28, 2025 at 2:28?PM Jorn Vernee <jorn.vernee at oracle.com>
>> wrote:
>>
>>> Hey Nir,
>>>
>>> The jextract API has been neglected for a while (as you've found).
>>> Initially it was a way of avoiding adding many flags to jextract, to do
>>> things like filtering, renaming, and other things. The idea being that
>>> if users wanted more control of what jextract did, they could use the
>>> API. But, now it seems like we're moving in that direction any way, with
>>> the JSON based configuration:
>>> https://bugs.openjdk.org/browse/CODETOOLS-7903788
>>>
>>> I think we need to re-asses which use cases the jextract API addresses,
>>> and whether using jextract through the ToolProvider interface, with the
>>> extended configuration options, is also an option.
>>>
>>> IIRC your use case is filtering the jextract output, right? Do you think
>>> it would be possible to use the ToolProvider interface with a
>>> combination of --dump-includes, and automatically generated
>>> --include-XXX flags, to achieve the same level of functionality?
>>>
>>> Jorn
>>>
>>> On 26-1-2025 08:51, Nir Lisker wrote:
>>> > Hi,
>>> >
>>> > There are several public methods the JextractTool exposes. Please
>>> > javadoc to these methods so tool users will know what they do and how
>>> > to use them.
>>> >
>>> > Thanks,
>>> > - Nir
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250130/476fcfdc/attachment-0001.htm>