From mcimadamore at openjdk.org  Tue Jul  1 08:59:51 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 1 Jul 2025 08:59:51 GMT
Subject: RFR: 7904049: Add LLM inference example to jextract samples [v2]
In-Reply-To: <5aA0hlx6BQWkGBdRtOMhzOFHDXoCuDD0nw7-0RkYzTo=.eecfce0a-f816-4a53-aa27-e4b0db01bb93@github.com>
References: <Pi1I3VCeS3_eSpFA6sfZRcT2NluSWr6V2Bi2FY9YeqM=.9cb6172d-f2c9-4cb0-8ea4-71a94de941f6@github.com>
 <5aA0hlx6BQWkGBdRtOMhzOFHDXoCuDD0nw7-0RkYzTo=.eecfce0a-f816-4a53-aa27-e4b0db01bb93@github.com>
Message-ID: <jE2l7YtL1tkDvHOS7cf-zWvVQrIKOF84Zxy8ZG5QPNA=.cc127734-00eb-4a6f-b2ba-d9b4be1bdf7c@github.com>

On Mon, 30 Jun 2025 10:16:35 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this PR to add an LLM inference example to the jextract samples.
>> 
>> Thanks!
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use `MemorySegment::reinterpret` to clean up objects
>   modify compile script slightly

Looks great!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jextract/pull/285#pullrequestreview-2974326850

From nbenalla at openjdk.org  Tue Jul  1 11:15:01 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 1 Jul 2025 11:15:01 GMT
Subject: Withdrawn: 7904051: Jextract should generate symbols in the same class
 consistently
In-Reply-To: <OApghLDAOu4TTo5_PxB9_mwv5lIjsT-zCUECAYu83l0=.7085d563-d306-4466-bf7f-9b55c9795b2e@github.com>
References: <OApghLDAOu4TTo5_PxB9_mwv5lIjsT-zCUECAYu83l0=.7085d563-d306-4466-bf7f-9b55c9795b2e@github.com>
Message-ID: <3zy9J-1coG5ZueGKkEuceNq_xhtNv3z_uZbFgohthJM=.19fb7c40-15dd-4896-b1b7-82f986fb6869@github.com>

On Mon, 30 Jun 2025 16:18:24 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Very simple change, done in a way to not break existing code as a simple sort would've changed the names of variables in the generated code.
> There was a test case that had to be updated.

This pull request has been closed without being integrated.

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

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

From nbenalla at openjdk.org  Wed Jul  2 11:34:51 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 2 Jul 2025 11:34:51 GMT
Subject: RFR: 7904049: Add LLM inference example to jextract samples [v2]
In-Reply-To: <5aA0hlx6BQWkGBdRtOMhzOFHDXoCuDD0nw7-0RkYzTo=.eecfce0a-f816-4a53-aa27-e4b0db01bb93@github.com>
References: <Pi1I3VCeS3_eSpFA6sfZRcT2NluSWr6V2Bi2FY9YeqM=.9cb6172d-f2c9-4cb0-8ea4-71a94de941f6@github.com>
 <5aA0hlx6BQWkGBdRtOMhzOFHDXoCuDD0nw7-0RkYzTo=.eecfce0a-f816-4a53-aa27-e4b0db01bb93@github.com>
Message-ID: <51UZY2N1B9azLXSirBEhixGzUkF5fJ6K1joQOTq6jsw=.ed141d8f-c8c3-4236-b623-2e73471cada7@github.com>

On Mon, 30 Jun 2025 10:16:35 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this PR to add an LLM inference example to the jextract samples.
>> 
>> Thanks!
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use `MemorySegment::reinterpret` to clean up objects
>   modify compile script slightly

Thanks for reviewing

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

PR Comment: https://git.openjdk.org/jextract/pull/285#issuecomment-3027523410

From duke at openjdk.org  Wed Jul  2 11:34:51 2025
From: duke at openjdk.org (duke)
Date: Wed, 2 Jul 2025 11:34:51 GMT
Subject: RFR: 7904049: Add LLM inference example to jextract samples [v2]
In-Reply-To: <5aA0hlx6BQWkGBdRtOMhzOFHDXoCuDD0nw7-0RkYzTo=.eecfce0a-f816-4a53-aa27-e4b0db01bb93@github.com>
References: <Pi1I3VCeS3_eSpFA6sfZRcT2NluSWr6V2Bi2FY9YeqM=.9cb6172d-f2c9-4cb0-8ea4-71a94de941f6@github.com>
 <5aA0hlx6BQWkGBdRtOMhzOFHDXoCuDD0nw7-0RkYzTo=.eecfce0a-f816-4a53-aa27-e4b0db01bb93@github.com>
Message-ID: <x9dPQ5TVH6xe1Y1bppPIi79Df7AtTw-XrzV7CXLCFQQ=.237bd0f5-70a0-4a33-a339-9db81f0f8e1b@github.com>

On Mon, 30 Jun 2025 10:16:35 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Please review this PR to add an LLM inference example to the jextract samples.
>> 
>> Thanks!
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use `MemorySegment::reinterpret` to clean up objects
>   modify compile script slightly

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

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

PR Comment: https://git.openjdk.org/jextract/pull/285#issuecomment-3027525932

From nbenalla at openjdk.org  Wed Jul  2 13:34:04 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 2 Jul 2025 13:34:04 GMT
Subject: Integrated: 7904049: Add LLM inference example to jextract samples
In-Reply-To: <Pi1I3VCeS3_eSpFA6sfZRcT2NluSWr6V2Bi2FY9YeqM=.9cb6172d-f2c9-4cb0-8ea4-71a94de941f6@github.com>
References: <Pi1I3VCeS3_eSpFA6sfZRcT2NluSWr6V2Bi2FY9YeqM=.9cb6172d-f2c9-4cb0-8ea4-71a94de941f6@github.com>
Message-ID: <qfm5EFukblPIYVLf2D2daFix5dZl5E5Pv962biD9LhQ=.30be30e2-5246-4132-b314-2a65db41ab2e@github.com>

On Wed, 25 Jun 2025 15:58:28 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Please review this PR to add an LLM inference example to the jextract samples.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 267a0abe
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jextract/commit/267a0abe441ba9bf2da3cfebd3dfd05c26bf464c
Stats:     188 lines in 4 files changed: 188 ins; 0 del; 0 mod

7904049: Add LLM inference example to jextract samples

Reviewed-by: mcimadamore

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

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

From duke at openjdk.org  Wed Jul  2 21:18:31 2025
From: duke at openjdk.org (Clayton Walker)
Date: Wed, 2 Jul 2025 21:18:31 GMT
Subject: RFR: Gradle cleanup
Message-ID: <2PIJo_9p4vA97BdA39UARTeRy2F_-5GZSH22o2cV_kM=.e89c04f2-30c8-487f-8ccb-a4732d49972c@github.com>

I've been doing some development, and came across a few warnings during build.

These are, [Project::task](https://docs.gradle.org/current/javadoc/org/gradle/api/Project.html#task(java.lang.String)) is now deprecated, avoiding Project::mkdir, project::delete and Project::getProjectDir as they cannot work under configuration-cache.

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

Commit messages:
 - Fix running with configuration-cache enabled
 - Fix deprecated mkdir call
 - Fix jar inputs
 - Remove use of deprecated task creation method

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

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

From duke at openjdk.org  Wed Jul  2 21:30:26 2025
From: duke at openjdk.org (Vivek Narang)
Date: Wed, 2 Jul 2025 21:30:26 GMT
Subject: RFR: Generate Java enums
Message-ID: <zGEF1fP9pnXpOD98WveVmIl6_b7U-KcTxwMVC55Qw0g=.a7eb7c84-6e82-483e-9711-f6a0d60a9805@github.com>

We are using jextract in our [cuVS Java](https://github.com/rapidsai/cuvs/tree/branch-25.08/java) project. As of now, jextract generates individual getter functions for the C enums. This results in code where it is difficult to disambiguate which getter functions are logically grouped together for a particular Enum. Additionally, given the lack of this capability, we also have to manually create and maintain Java enums for each enum in the C layer.

In this PR, I wish to introduce an option to additionally generate Java enums by passing an optional flag `--generate-java-enums`. In case a Java user wishes to use bitwise operations on the enums, they can use the enum's `.ordinal()` method for this. The original static getter methods will still be generated as before. 

Example C enum:

enum SIZE {
   S,
   M,
   L
};

Produces the following with jextract:

private static final int S = (int)0L;
public static int S() {
     return S;
}

private static final int M = (int)1L;
public static int M() {
     return M;
}

private static final int L = (int)2L;
public static int L() {
     return L;
}

With this feature enabled using the `--generate-java-enums` flag, the following enum is generated (in addition to the above):

public enum Size {
    S(0),
    M(1),
    L(2);

    private final int value;

    private Size(int value) {;
        this.value = value;
    }

    public int getValue() {
        return this.value;
    }
}

This PR is created against the `jdk22` branch. I will rebase it to `master` branch if needed.

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

Commit messages:
 - Remove extra space in messages.properties
 - Generate enums in header file instead
 - Initial work

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

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

From duke at openjdk.org  Wed Jul  2 22:13:50 2025
From: duke at openjdk.org (Clayton Walker)
Date: Wed, 2 Jul 2025 22:13:50 GMT
Subject: RFR: Gradle cleanup
In-Reply-To: <2PIJo_9p4vA97BdA39UARTeRy2F_-5GZSH22o2cV_kM=.e89c04f2-30c8-487f-8ccb-a4732d49972c@github.com>
References: <2PIJo_9p4vA97BdA39UARTeRy2F_-5GZSH22o2cV_kM=.e89c04f2-30c8-487f-8ccb-a4732d49972c@github.com>
Message-ID: <D4eAuHuMAxFkqnxuNKtsbsGlAyuMyXUOkdQs5wltkKQ=.f0438353-4c36-4322-beec-f83ee4f580d4@github.com>

On Mon, 16 Jun 2025 22:15:12 GMT, Clayton Walker <duke at openjdk.org> wrote:

> I've been doing some development, and came across a few warnings during build.
> 
> These are, [Project::task](https://docs.gradle.org/current/javadoc/org/gradle/api/Project.html#task(java.lang.String)) is now deprecated, avoiding Project::mkdir, project::delete and Project::getProjectDir as they cannot work under configuration-cache.

As a follow-up I'd like to see all of the explicit `dependsOn` get removed in favor of implicit dependencies based on manually specified task inputs and outputs. https://docs.gradle.org/9.0.0-rc-1/userguide/best_practices_tasks.html#avoid_depends_on

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

PR Comment: https://git.openjdk.org/jextract/pull/283#issuecomment-3029455960

From liach at openjdk.org  Wed Jul  2 23:31:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Jul 2025 23:31:52 GMT
Subject: RFR: Gradle cleanup
In-Reply-To: <2PIJo_9p4vA97BdA39UARTeRy2F_-5GZSH22o2cV_kM=.e89c04f2-30c8-487f-8ccb-a4732d49972c@github.com>
References: <2PIJo_9p4vA97BdA39UARTeRy2F_-5GZSH22o2cV_kM=.e89c04f2-30c8-487f-8ccb-a4732d49972c@github.com>
Message-ID: <cnoZ88Z89AG9B_rPChJ-HfW6QlNfGZ8FOg6NmI_BiP4=.a9c5851b-14d3-4706-ba4f-5fd5414e5b94@github.com>

On Mon, 16 Jun 2025 22:15:12 GMT, Clayton Walker <duke at openjdk.org> wrote:

> I've been doing some development, and came across a few warnings during build.
> 
> These are, [Project::task](https://docs.gradle.org/current/javadoc/org/gradle/api/Project.html#task(java.lang.String)) is now deprecated, avoiding Project::mkdir, project::delete and Project::getProjectDir as they cannot work under configuration-cache.

build.gradle line 101:

> 99: 
> 100:     // if these inputs or outputs change, gradle will rerun the task
> 101:     inputs.file(tasks.named('jar', Jar).flatMap { it.archiveFile})

Suggestion:

    inputs.file(tasks.named('jar', Jar).flatMap { it.archiveFile })

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

PR Review Comment: https://git.openjdk.org/jextract/pull/283#discussion_r2181147694

From duke at openjdk.org  Thu Jul  3 05:37:42 2025
From: duke at openjdk.org (Clayton Walker)
Date: Thu, 3 Jul 2025 05:37:42 GMT
Subject: RFR: Gradle cleanup [v2]
In-Reply-To: <2PIJo_9p4vA97BdA39UARTeRy2F_-5GZSH22o2cV_kM=.e89c04f2-30c8-487f-8ccb-a4732d49972c@github.com>
References: <2PIJo_9p4vA97BdA39UARTeRy2F_-5GZSH22o2cV_kM=.e89c04f2-30c8-487f-8ccb-a4732d49972c@github.com>
Message-ID: <UROSrfvvVvtkneoQjkidRVF9WItI60905BesOAKGYeQ=.b95604d3-2277-4a05-9ad4-c313ffff25dd@github.com>

> I've been doing some development, and came across a few warnings during build.
> 
> These are, [Project::task](https://docs.gradle.org/current/javadoc/org/gradle/api/Project.html#task(java.lang.String)) is now deprecated, avoiding Project::mkdir, project::delete and Project::getProjectDir as they cannot work under configuration-cache.

Clayton Walker has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Fix running with configuration-cache enabled

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

Changes:
  - all: https://git.openjdk.org/jextract/pull/283/files
  - new: https://git.openjdk.org/jextract/pull/283/files/d576694e..c79d28e5

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

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

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

From duke at openjdk.org  Thu Jul  3 05:37:43 2025
From: duke at openjdk.org (Clayton Walker)
Date: Thu, 3 Jul 2025 05:37:43 GMT
Subject: RFR: Gradle cleanup [v2]
In-Reply-To: <cnoZ88Z89AG9B_rPChJ-HfW6QlNfGZ8FOg6NmI_BiP4=.a9c5851b-14d3-4706-ba4f-5fd5414e5b94@github.com>
References: <2PIJo_9p4vA97BdA39UARTeRy2F_-5GZSH22o2cV_kM=.e89c04f2-30c8-487f-8ccb-a4732d49972c@github.com>
 <cnoZ88Z89AG9B_rPChJ-HfW6QlNfGZ8FOg6NmI_BiP4=.a9c5851b-14d3-4706-ba4f-5fd5414e5b94@github.com>
Message-ID: <lNdXR5TwBRCEG57jbmjngDj-SJAl5wnGyspbcF8jfQI=.aeda5d3f-d30a-45c7-bb82-b0e9beaa0251@github.com>

On Wed, 2 Jul 2025 23:29:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Clayton Walker has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   Fix running with configuration-cache enabled
>
> build.gradle line 101:
> 
>> 99: 
>> 100:     // if these inputs or outputs change, gradle will rerun the task
>> 101:     inputs.file(tasks.named('jar', Jar).flatMap { it.archiveFile})
> 
> Suggestion:
> 
>     inputs.file(tasks.named('jar', Jar).flatMap { it.archiveFile })

Fixed!

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

PR Review Comment: https://git.openjdk.org/jextract/pull/283#discussion_r2181804554

From mcimadamore at openjdk.org  Thu Jul  3 09:40:55 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 3 Jul 2025 09:40:55 GMT
Subject: RFR: Generate Java enums
In-Reply-To: <zGEF1fP9pnXpOD98WveVmIl6_b7U-KcTxwMVC55Qw0g=.a7eb7c84-6e82-483e-9711-f6a0d60a9805@github.com>
References: <zGEF1fP9pnXpOD98WveVmIl6_b7U-KcTxwMVC55Qw0g=.a7eb7c84-6e82-483e-9711-f6a0d60a9805@github.com>
Message-ID: <6l9HLjo-lG7jlTreLx9ML3vYb-VFw1TIk0Wi7hj2tjQ=.7ca76e76-17aa-40c0-b8ae-89ec11097a22@github.com>

On Fri, 20 Jun 2025 17:09:19 GMT, Vivek Narang <duke at openjdk.org> wrote:

> We are using jextract in our [cuVS Java](https://github.com/rapidsai/cuvs/tree/branch-25.08/java) project. As of now, jextract generates individual getter functions for the C enums. This results in code where it is difficult to disambiguate which getter functions are logically grouped together for a particular Enum. Additionally, given the lack of this capability, we also have to manually create and maintain Java enums for each enum in the C layer.
> 
> In this PR, I wish to introduce an option to additionally generate Java enums by passing an optional flag `--generate-java-enums`. In case a Java user wishes to use bitwise operations on the enums, they can use the enum's `.ordinal()` method for this. The original static getter methods will still be generated as before. 
> 
> Example C enum:
> 
> enum SIZE {
>    S,
>    M,
>    L
> };
> 
> Produces the following with jextract:
> 
> private static final int S = (int)0L;
> public static int S() {
>      return S;
> }
> 
> private static final int M = (int)1L;
> public static int M() {
>      return M;
> }
> 
> private static final int L = (int)2L;
> public static int L() {
>      return L;
> }
> 
> With this feature enabled using the `--generate-java-enums` flag, the following enum is generated (in addition to the above):
> 
> public enum Size {
>     S(0),
>     M(1),
>     L(2);
> 
>     private final int value;
> 
>     private Size(int value) {;
>         this.value = value;
>     }
> 
>     public int getValue() {
>         return this.value;
>     }
> }
> 
> This PR is created against the `jdk22` branch. I will rebase it to `master` branch if needed.

In general we have not used the translation to Java enum because it's not 100% semantics preserving. In C enum constants are more of loose constants -- given:


enum Color
{
    Red,
    Green,
    Blue,
}


C code can do things like `Red | Blue` -- which are not possible with Java enums.

Moreover, C enum constants live in the same namespace as global variables. So it seemed again honest to allow clients to access enum constants directly after having imported (statically) the main generated header class.

While in some ways using Java enums to model C enums look more natural, it also represents a significant departure from C. I can imagine that some simple uses of C enums would be quite happy with the approach you propose -- but this approach would not scale for more complex uses.

The philosophy of jextract has, so far, been to generate a set of bindings that was as close as possible to the semantics of the extracted header. That has been the main guiding principle. There's a lot of "creativity" jextract could provide on top (and enums is a good example), but adding creativity almost always results in binding that work better in some cases and worse in others. For these reasons, I don't think this PR fits well with the design principles of jextract.

One less radical move could be to give up to the "single namespace" property, and at least group related enum constants together, under a separate generated class. That would mean the Java code would require more "qualifiers" than the associated C code, but with some better separation. Would something like that be enough? Or do you really need these constants to be enum constants (e.g. because you use them in exhaustive switches etc.) ?

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

PR Comment: https://git.openjdk.org/jextract/pull/284#issuecomment-3031589143

From mcimadamore at openjdk.org  Thu Jul  3 09:46:58 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 3 Jul 2025 09:46:58 GMT
Subject: RFR: Generate Java enums
In-Reply-To: <zGEF1fP9pnXpOD98WveVmIl6_b7U-KcTxwMVC55Qw0g=.a7eb7c84-6e82-483e-9711-f6a0d60a9805@github.com>
References: <zGEF1fP9pnXpOD98WveVmIl6_b7U-KcTxwMVC55Qw0g=.a7eb7c84-6e82-483e-9711-f6a0d60a9805@github.com>
Message-ID: <zpIN_uLgAsu4AR_s1BsUf1A2Or3vScL_B88hqUtb9wk=.e72e3ce8-84fa-4223-8722-daf1b98f000c@github.com>

On Fri, 20 Jun 2025 17:09:19 GMT, Vivek Narang <duke at openjdk.org> wrote:

> We are using jextract in our [cuVS Java](https://github.com/rapidsai/cuvs/tree/branch-25.08/java) project. As of now, jextract generates individual getter functions for the C enums. This results in code where it is difficult to disambiguate which getter functions are logically grouped together for a particular Enum. Additionally, given the lack of this capability, we also have to manually create and maintain Java enums for each enum in the C layer.
> 
> In this PR, I wish to introduce an option to additionally generate Java enums by passing an optional flag `--generate-java-enums`. In case a Java user wishes to use bitwise operations on the enums, they can use the enum's `.ordinal()` method for this. The original static getter methods will still be generated as before. 
> 
> Example C enum:
> 
> enum SIZE {
>    S,
>    M,
>    L
> };
> 
> Produces the following with jextract:
> 
> private static final int S = (int)0L;
> public static int S() {
>      return S;
> }
> 
> private static final int M = (int)1L;
> public static int M() {
>      return M;
> }
> 
> private static final int L = (int)2L;
> public static int L() {
>      return L;
> }
> 
> With this feature enabled using the `--generate-java-enums` flag, the following enum is generated (in addition to the above):
> 
> public enum Size {
>     S(0),
>     M(1),
>     L(2);
> 
>     private final int value;
> 
>     private Size(int value) {;
>         this.value = value;
>     }
> 
>     public int getValue() {
>         return this.value;
>     }
> }
> 
> This PR is created against the `jdk22` branch. I will rebase it to `master` branch if needed.

Another thing that came to mind: if we translate C enums as Java enums -- how is a native function accepting a C enum type translated? If we translate it as an int-accepting function (what we do now) then the Java enum constants cannot be used to call into native functions. If we translate it as a Java-enum-accepting function, then we would make these function stricter than their C counterparts.

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

PR Comment: https://git.openjdk.org/jextract/pull/284#issuecomment-3031606147

From liach at openjdk.org  Thu Jul  3 15:23:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 3 Jul 2025 15:23:51 GMT
Subject: RFR: Gradle cleanup [v2]
In-Reply-To: <UROSrfvvVvtkneoQjkidRVF9WItI60905BesOAKGYeQ=.b95604d3-2277-4a05-9ad4-c313ffff25dd@github.com>
References: <2PIJo_9p4vA97BdA39UARTeRy2F_-5GZSH22o2cV_kM=.e89c04f2-30c8-487f-8ccb-a4732d49972c@github.com>
 <UROSrfvvVvtkneoQjkidRVF9WItI60905BesOAKGYeQ=.b95604d3-2277-4a05-9ad4-c313ffff25dd@github.com>
Message-ID: <81HWuwzqNRclBJqZSlNUrBP-x1FOecDc86z2Ej99u8E=.f1977a06-3c31-4842-a335-fb3f32129567@github.com>

On Thu, 3 Jul 2025 05:37:42 GMT, Clayton Walker <duke at openjdk.org> wrote:

>> I've been doing some development, and came across a few warnings during build.
>> 
>> These are, [Project::task](https://docs.gradle.org/current/javadoc/org/gradle/api/Project.html#task(java.lang.String)) is now deprecated, avoiding Project::mkdir, project::delete and Project::getProjectDir as they cannot work under configuration-cache.
>
> Clayton Walker has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Fix running with configuration-cache enabled

Haven't used gradle in a while so don't know about the latest deprecations, but these changes are existing gradle styles and make sense.

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

Marked as reviewed by liach (no project role).

PR Review: https://git.openjdk.org/jextract/pull/283#pullrequestreview-2983629813