RFR: 8360586: JavaFX build uses deprecated features that will be removed in gradle 9 [v2]

[Kevin Rushforth]

On Wed, 24 Sep 2025 03:22:16 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> **Issue**:
>> Below two Gradle 9.0.0 specific warnings are observed with current grade 8.14.2
>> 1. The `Project.exec(Closure)` method has been deprecated. This is scheduled to be removed in Gradle 9.0
>> 2. Using method `javaexec(Closure)` has been deprecated. This is scheduled to be removed in Gradle 9.0.
>> 
>> Both these methods are removed in Gradle 9.0.0.
>> Hence they should be replaced with appropriate APIs.
>> Refer: https://docs.gradle.org/8.14.2/userguide/upgrading_version_8.html#deprecated_project_exec
>> 
>> **Fix**:
>> Both warnings can be fixed by replacing the calls with` ExecOperations.exec(Action)`.
>> There are two different scenarios where we use the above two APIs.
>> - Gradle files
>> - Groovy class files
>> => In Both the scenarios, we have to use the `ExecOperations.exec(Action)`, but the approach differs.
>> 
>> 1. Gradle file
>>     - The calls are simply replaced as,
>>         * `Project.exec {` is replaced with `execOps.exec { ExecSpec spec ->`
>>         * `Project.javaexex {`  is replaced with `execOps.javaexec { JavaExecSpec spec ->`
>> 2. For Groovy classes
>>     - `ExecOperations` needs to be **injected** using `@Inject` tag
>>     1. `NativeCompileTask` class
>>         - In the `NativeCompileTask` class, a method `execCompile()` is added which executes an action.
>>         - The child classes of `NativeCompileTask`, use this `execCompile()` method.
>>     2. Other classes are not related to each other. They independently execute the respective action.
>> 
>> **Verification**:
>> 1. Run all gradle tasks with **—warning-mode all** option, with gradle 8.14.2 
>> 2. No Gradle 9.0.0 specific warning is seen in build log
>> 4. Build/all tasks complete successfully.
>
> Ambarish Rapte 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into gradle-900-warnings
>  - replace project.exec and project.javaexec

I left a suggestion for eliminating the type of the closure argument. For example, I think you can use:


    execOps.exec { spec ->


This applies to all of the exec calls in the various gradle and groovy files you had to change). If you prefer to keep the explicit type, it's OK, too. I just think it might be cleaner without it.

Also, it looks like you missed one or more warnings. I still see this in the log:


2025-09-24T03:23:05.2477610Z Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.
2025-09-24T03:23:05.2477970Z 
2025-09-24T03:23:05.2478350Z You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.
2025-09-24T03:23:05.2478790Z 
2025-09-24T03:23:05.2479320Z For more on this, please refer to https://docs.gradle.org/8.14.2/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.
2025-09-24T03:23:05.2479870Z 
2025-09-24T03:23:05.2480020Z BUILD SUCCESSFUL in 3m 32s


See, for example:

https://github.com/arapte/jfx/actions/runs/17965277238/job/51102558023

build.gradle line 888:

> 886:                         pkgdir.mkdirs()
> 887:                         def execOps = project.services.get(ExecOperations)
> 888:                         execOps.exec { ExecSpec spec ->

Suggestion:

                        execOps.exec { spec ->


We generally don't include the type of a closure argument, unless it's ambiguous (which I don't think it is here).

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

PR Review: https://git.openjdk.org/jfx/pull/1918#pullrequestreview-3269537051
PR Review Comment: https://git.openjdk.org/jfx/pull/1918#discussion_r2380379516