<commit_before>The Gradle team is excited to announce Gradle @version@.

This release includes [building code and running Gradle with Java 18](#java18), [building code with Groovy 4](#groovy4), [much more responsive continuous builds](#continuous-build), [improved diagnostics for dependency resolution](#dependency-diagnostics), as well as [configuration cache improvements](#configuration-cache-improvements) for better performance, [Adoptium toolchain provisioning](#adoptium-provisioning) for JVM, and more.

We would like to thank the following community members for their contributions to this release of Gradle:
[<NAME>](https://github.com/jkasten2),
[Marcono1234](https://github.com/Marcono1234),
[mataha](https://github.com/mataha),
[<NAME>](https://github.com/denshade),
[kiwi-oss](https://github.com/kiwi-oss),
[<NAME>](https://github.com/stefanneuhaus),
[<NAME>](https://github.com/smoothreggae),
[<NAME>](https://github.com/apalopta),
[<NAME>](https://github.com/Vampire),
[<NAME>](https://github.com/davidburstrom),
[<NAME>](https://github.com/vlsi),
[<NAME>](https://github.com/rweisleder),
[<NAME>](https://github.com/grossws),
[<NAME>](https://github.com/DavidOpDeBeeck),
[aSemy](https://github.com/aSemy),
[<NAME>](https://github.com/breskeby),
[<NAME>](https://github.com/JLLeitschuh),
[<NAME>](https://github.com/jamietanna),
[<NAME>](https://github.com/scaventz),
[<NAME>](https://github.com/att55),
[<NAME>](https://github.com/acktsap),
[<NAME>](https://github.com/DavidOpDeBeeck),
[<NAME>](https://github.com/codecholeric),
[<NAME>](https://github.com/AlexLandau),
[<NAME>](https://github.com/solvingj),
[<NAME>](https://github.com/T-A-B),
[<NAME>](https://github.com/3flex),
[<NAME>](https://github.com/filip-daca),
[<NAME>](https://github.com/xdevs23),
[<NAME>](https://github.com/rieske),
[<NAME>](https://github.com/yasmans)

## Upgrade instructions

Switch your build to use Gradle @version@ by updating your wrapper:

`./gradlew wrapper --gradle-version=@version@`

See the [Gradle 7.x upgrade guide](userguide/upgrading_version_7.html#changes_@baseVersion@) to learn about deprecations, breaking changes and other considerations when upgrading to Gradle @version@.

For Java, Groovy, Kotlin and Android compatibility, see the [full compatibility notes](userguide/compatibility.html).

## New features and usability improvements

<a name="java18"></a>
### Support for Java 18

Gradle now supports running on and building with [Java 18](https://openjdk.java.net/projects/jdk/18/).

<a name="groovy4"></a>
### Support for Groovy 4

Gradle now supports building software using Groovy 4.0. Note that Groovy DSL buildscripts still use Groovy 3.

<a name="continuous-build"></a>
### Continuous Build is much more responsive on Windows and macOS with Java 9+

[Continuous Build](userguide/command_line_interface.html#sec:continuous_build) automatically re-executes the build with the same requested tasks when inputs change.
This allows for continuous feedback during development.

Because of the internal changes in the JDK, Continuous Build did not work well on Windows and macOS on Java 9 and higher.
It could take up to 10 seconds to detect a change and trigger a build.

Now Gradle picks up changes nearly instantly on Windows and macOS for all Java versions as well, making Continuous Build respond quickly on all major operating systems. This is because Gradle now uses its own robust and natively implemented file system watching system instead of relying on the generic API in the JDK.

<a name="dependency-diagnostics"></a>
### Improved diagnostic reports for dependency resolution

#### Outgoing Variants

The `outgoingVariants` report now provides additional information that allows further insight into [variant aware dependency resolution](userguide/variant_model.html#sec:variant-aware-matching) results.

This report is useful when determining why a particular variant of this producer project was selected by another consumer project when the producer depends upon the consumer.  Run the report from the producer project, to list every variant built by it (including secondary variants only visible to other local projects).  The output contains the capabilities and attributes present on each variant of the producer, along with other information detailed below.  This output can be compared against the output of the new [`resolvableConfigurations` report](#resolvable-configurations) run in the consumer.
1. Descriptions are now printed for secondary variants, if present.
2. Configurations using `@Incubating` attributes are marked with an `(i)`.
3. The legend at the bottom of the report clarifies the usage of secondary variants.
4. The formatting (and coloring for rich console) of the output is now clearer and more consistent with other reports.
5. Capabilities, Attributes and Artifact lists are alphabetically sorted.
6. Classifiers are now printed next to artifacts if present.
7. New messages when using `--all` and `--variant` options to better describe results (or the lack thereof)

See the [OutgoingVariantsReport](dsl/org.gradle.api.tasks.diagnostics.OutgoingVariantsReport.html) DSL reference for more details.

#### Resolvable Configurations

There is a new `resolvableConfigurations` report available which will display information about all the configurations in a project that can be resolved.

This report compliments the [`outgoingVariants` report](#outgoing-variants) and is meant to be run from the consumer side of a dependency to determine why a particular variant of a producer project was selected by this consumer project when the consumer depends upon the producer.  It includes the following information:

- Description, Attributes and (directly) extended Configurations
- A `--recursive` option flag can be set to display all configurations which are extended transitively
- Attributes affected by Compatibility or Disambiguation rules during resolution listed
- A `--configuration` option can limit this report to a single configuration
- A `--all` option flag can be set to include legacy configurations which are both resolvable and consumable; these will be hidden by default
-
See the [ResolvableConfigurations](dsl/org.gradle.api.tasks.diagnostics.ResolvableConfigurations.html) DSL reference for more details.

#### Dependency Insights

The `dependencyInsight` report provides information about a specific dependency, including what variant was selected, and the attributes used during resolution.

The report now uses a table to display variants, which makes it easier to tell where attribute values are from, and see why a particular variant was selected:
1. The variant name is listed at the top, after the word "Variant"
2. The variant output is now in table format.
3. Attributes only present in the variant's metadata only contain text in the "Provided" column
4. Attributes present in both the variant's metadata and requested by the configuration contain text in both columns
5. Attributes only requested by the configuration only contain text in the "Requested" column
6. The table is sorted first by groups (3), (4), and (5); then alphabetically inside each group.

<a name="dependency-resolution-results-task-inputs"></a>
### Dependency resolution results can be used as task inputs

Tasks may need to access dependency resolution results.
For example, built-in tasks like `dependencies` and `dependencyInsight` do so in order to provide reporting about resolved artifacts and dependency graphs.
Other tasks may produce file outputs based on dependency resolution results.
Previously, it was only possible by performing dependency resolution in a task action.
However, this resulted in suboptimal performance.

Starting with Gradle 7.5 it is now possible to declare dependency resolution results as task inputs.

This allows writing tasks which consume dependency resolution results.
Declaring such inputs instead of doing undeclared dependency resolution in task actions allows Gradle to optimise for build incrementality.
Additionally, these new types of task inputs are fully supported by the [configuration cache](userguide/configuration_cache.html).

You can learn more in the [Authoring Tasks](userguide/more_about_tasks.html#sec:task_input_using_dependency_resolution_results) user manual chapter and with the dedicated [sample](samples/sample_tasks_with_dependency_resolution_result_inputs.html).

<a name="configuration-cache-improvements"></a>
### Configuration cache improvements

The [configuration cache](userguide/configuration_cache.html) improves build time by caching the result of the configuration phase and reusing this for subsequent builds.

#### Running external processes at configuration time

Previously, external processes started with `exec` or `javaexec` APIs were ignored by configuration cache, and it could be a potential correctness issue if the output of the external process affects the configuration.

A [new Provider-based API](javadoc/org/gradle/api/provider/ProviderFactory.html#exec-org.gradle.api.Action-) is
now available to obtain the output of the external process in the configuration-cache-compatible way. The `exec` and `javaexec` APIs are now [disallowed](userguide/configuration_cache.html#config_cache:requirements:external_processes) if the configuration cache is enabled in order to prevent potential issues.

If a more complex interaction with the external process is necessary, then a custom [`ValueSource`](javadoc/org/gradle/api/provider/ValueSource.html) implementation
can be used. The injected [`ExecOperations`](javadoc/org/gradle/process/ExecOperations.html) service should be used to run the external process.

#### Files read at configuration time become build configuration inputs

Files read at configuration time with `FileInputStream` or some Kotlin APIs now automatically become build configuration inputs. The configuration cache is invalidated if the contents of such file(s) change between builds.

Previously, file reads were ignored, and it could be a potential correctness issue if the contents of the file(s) affected the configuration.

#### New ways to access environment without unnecessary invalidations of the configuration cache

Since the automatic build configuration inputs detection was introduced in Gradle 7.4, some common patterns of reading subsets of environment variables or system properties were causing excessive invalidations of the configuration cache, leading to suboptimal performance. For example, iterating over all environment variables to find the ones with names starting with some prefix caused all available variables, even the unrelated ones, to become configuration inputs.

Two new options are now available to mitigate that. For simpler use cases, there are the Provider-based APIs to access [system properties](javadoc/org/gradle/api/provider/ProviderFactory.html#systemPropertiesPrefixedBy-java.lang.String-) or [environment variables](javadoc//org/gradle/api/provider/ProviderFactory.html#environmentVariablesPrefixedBy-java.lang.String-) with names starting with some prefix. Advanced processing, like filtering names with regular expression, can be done inside a custom [`ValueSource`](javadoc/org/gradle/api/provider/ValueSource.html) implementation. Reading a file, an environment variable, or a system property no longer adds a build configuration input inside the implementation of the `ValueSource`. The value of the `ValueSource` is recomputed each time the build runs, and the configuration cache entry is only invalidated if the value changes.

#### New compatible plugins and tasks

The [`kotlin-dsl`](userguide/kotlin_dsl.html#sec:kotlin-dsl_plugin) plugin is now compatible with the configuration cache.

The `dependencyInsight`, `outgoingVariants` and `resolvableConfigurations` tasks are now compatible with the configuration cache.

### JVM toolchains improvements

[Java toolchains](userguide/toolchains.html) provide an easy way to declare which Java version your project should be built with.
By default, Gradle will [detect installed JDKs](userguide/toolchains.html#sec:auto_detection) or automatically download new toolchain versions.
<commit_msg>Add STABLE_CONFIGURATION_CACHE feature flag to release notes<commit_after>The Gradle team is excited to announce Gradle @version@.

This release includes [building code and running Gradle with Java 18](#java18), [building code with Groovy 4](#groovy4), [much more responsive continuous builds](#continuous-build), [improved diagnostics for dependency resolution](#dependency-diagnostics), as well as [configuration cache improvements](#configuration-cache-improvements) for better performance, [Adoptium toolchain provisioning](#adoptium-provisioning) for JVM, and more.

We would like to thank the following community members for their contributions to this release of Gradle:
[<NAME>](https://github.com/jkasten2),
[Marcono1234](https://github.com/Marcono1234),
[mataha](https://github.com/mataha),
[<NAME>](https://github.com/denshade),
[kiwi-oss](https://github.com/kiwi-oss),
[<NAME>](https://github.com/stefanneuhaus),
[<NAME>](https://github.com/smoothreggae),
[<NAME>](https://github.com/apalopta),
[<NAME>](https://github.com/Vampire),
[<NAME>](https://github.com/davidburstrom),
[<NAME>](https://github.com/vlsi),
[<NAME>](https://github.com/rweisleder),
[<NAME>](https://github.com/grossws),
[David <NAME>](https://github.com/DavidOpDeBeeck),
[aSemy](https://github.com/aSemy),
[<NAME>](https://github.com/breskeby),
[<NAME>](https://github.com/JLLeitschuh),
[<NAME>](https://github.com/jamietanna),
[<NAME>](https://github.com/scaventz),
[<NAME>](https://github.com/att55),
[<NAME>](https://github.com/acktsap),
[David <NAME>](https://github.com/DavidOpDeBeeck),
[<NAME>](https://github.com/codecholeric),
[<NAME>](https://github.com/AlexLandau),
[<NAME>](https://github.com/solvingj),
[<NAME>](https://github.com/T-A-B),
[Matthew Haughton](https://github.com/3flex),
[<NAME>](https://github.com/filip-daca),
[<NAME>](https://github.com/xdevs23),
[<NAME>](https://github.com/rieske),
[<NAME>](https://github.com/yasmans)

## Upgrade instructions

Switch your build to use Gradle @version@ by updating your wrapper:

`./gradlew wrapper --gradle-version=@version@`

See the [Gradle 7.x upgrade guide](userguide/upgrading_version_7.html#changes_@baseVersion@) to learn about deprecations, breaking changes and other considerations when upgrading to Gradle @version@.

For Java, Groovy, Kotlin and Android compatibility, see the [full compatibility notes](userguide/compatibility.html).

## New features and usability improvements

<a name="java18"></a>
### Support for Java 18

Gradle now supports running on and building with [Java 18](https://openjdk.java.net/projects/jdk/18/).

<a name="groovy4"></a>
### Support for Groovy 4

Gradle now supports building software using Groovy 4.0. Note that Groovy DSL buildscripts still use Groovy 3.

<a name="continuous-build"></a>
### Continuous Build is much more responsive on Windows and macOS with Java 9+

[Continuous Build](userguide/command_line_interface.html#sec:continuous_build) automatically re-executes the build with the same requested tasks when inputs change.
This allows for continuous feedback during development.

Because of the internal changes in the JDK, Continuous Build did not work well on Windows and macOS on Java 9 and higher.
It could take up to 10 seconds to detect a change and trigger a build.

Now Gradle picks up changes nearly instantly on Windows and macOS for all Java versions as well, making Continuous Build respond quickly on all major operating systems. This is because Gradle now uses its own robust and natively implemented file system watching system instead of relying on the generic API in the JDK.

<a name="dependency-diagnostics"></a>
### Improved diagnostic reports for dependency resolution

#### Outgoing Variants

The `outgoingVariants` report now provides additional information that allows further insight into [variant aware dependency resolution](userguide/variant_model.html#sec:variant-aware-matching) results.

This report is useful when determining why a particular variant of this producer project was selected by another consumer project when the producer depends upon the consumer.  Run the report from the producer project, to list every variant built by it (including secondary variants only visible to other local projects).  The output contains the capabilities and attributes present on each variant of the producer, along with other information detailed below.  This output can be compared against the output of the new [`resolvableConfigurations` report](#resolvable-configurations) run in the consumer.
1. Descriptions are now printed for secondary variants, if present.
2. Configurations using `@Incubating` attributes are marked with an `(i)`.
3. The legend at the bottom of the report clarifies the usage of secondary variants.
4. The formatting (and coloring for rich console) of the output is now clearer and more consistent with other reports.
5. Capabilities, Attributes and Artifact lists are alphabetically sorted.
6. Classifiers are now printed next to artifacts if present.
7. New messages when using `--all` and `--variant` options to better describe results (or the lack thereof)

See the [OutgoingVariantsReport](dsl/org.gradle.api.tasks.diagnostics.OutgoingVariantsReport.html) DSL reference for more details.

#### Resolvable Configurations

There is a new `resolvableConfigurations` report available which will display information about all the configurations in a project that can be resolved.

This report compliments the [`outgoingVariants` report](#outgoing-variants) and is meant to be run from the consumer side of a dependency to determine why a particular variant of a producer project was selected by this consumer project when the consumer depends upon the producer.  It includes the following information:

- Description, Attributes and (directly) extended Configurations
- A `--recursive` option flag can be set to display all configurations which are extended transitively
- Attributes affected by Compatibility or Disambiguation rules during resolution listed
- A `--configuration` option can limit this report to a single configuration
- A `--all` option flag can be set to include legacy configurations which are both resolvable and consumable; these will be hidden by default
-
See the [ResolvableConfigurations](dsl/org.gradle.api.tasks.diagnostics.ResolvableConfigurations.html) DSL reference for more details.

#### Dependency Insights

The `dependencyInsight` report provides information about a specific dependency, including what variant was selected, and the attributes used during resolution.

The report now uses a table to display variants, which makes it easier to tell where attribute values are from, and see why a particular variant was selected:
1. The variant name is listed at the top, after the word "Variant"
2. The variant output is now in table format.
3. Attributes only present in the variant's metadata only contain text in the "Provided" column
4. Attributes present in both the variant's metadata and requested by the configuration contain text in both columns
5. Attributes only requested by the configuration only contain text in the "Requested" column
6. The table is sorted first by groups (3), (4), and (5); then alphabetically inside each group.

<a name="dependency-resolution-results-task-inputs"></a>
### Dependency resolution results can be used as task inputs

Tasks may need to access dependency resolution results.
For example, built-in tasks like `dependencies` and `dependencyInsight` do so in order to provide reporting about resolved artifacts and dependency graphs.
Other tasks may produce file outputs based on dependency resolution results.
Previously, it was only possible by performing dependency resolution in a task action.
However, this resulted in suboptimal performance.

Starting with Gradle 7.5 it is now possible to declare dependency resolution results as task inputs.

This allows writing tasks which consume dependency resolution results.
Declaring such inputs instead of doing undeclared dependency resolution in task actions allows Gradle to optimise for build incrementality.
Additionally, these new types of task inputs are fully supported by the [configuration cache](userguide/configuration_cache.html).

You can learn more in the [Authoring Tasks](userguide/more_about_tasks.html#sec:task_input_using_dependency_resolution_results) user manual chapter and with the dedicated [sample](samples/sample_tasks_with_dependency_resolution_result_inputs.html).

<a name="configuration-cache-improvements"></a>
### Configuration cache improvements

The [configuration cache](userguide/configuration_cache.html) improves build time by caching the result of the configuration phase and reusing this for subsequent builds.

#### Running external processes at configuration time

Previously, external processes started with `exec` or `javaexec` APIs were ignored by configuration cache, and it could be a potential correctness issue if the output of the external process affects the configuration.

A [new Provider-based API](javadoc/org/gradle/api/provider/ProviderFactory.html#exec-org.gradle.api.Action-) is
now available to obtain the output of the external process in the configuration-cache-compatible way. The `exec` and `javaexec` APIs are now [disallowed](userguide/configuration_cache.html#config_cache:requirements:external_processes) if the configuration cache is enabled in order to prevent potential issues.

If a more complex interaction with the external process is necessary, then a custom [`ValueSource`](javadoc/org/gradle/api/provider/ValueSource.html) implementation
can be used. The injected [`ExecOperations`](javadoc/org/gradle/process/ExecOperations.html) service should be used to run the external process.

#### Files read at configuration time become build configuration inputs

Files read at configuration time with `FileInputStream` or some Kotlin APIs now automatically become build configuration inputs. The configuration cache is invalidated if the contents of such file(s) change between builds.

Previously, file reads were ignored, and it could be a potential correctness issue if the contents of the file(s) affected the configuration.

#### New ways to access environment without unnecessary invalidations of the configuration cache

Since the automatic build configuration inputs detection was introduced in Gradle 7.4, some common patterns of reading subsets of environment variables or system properties were causing excessive invalidations of the configuration cache, leading to suboptimal performance. For example, iterating over all environment variables to find the ones with names starting with some prefix caused all available variables, even the unrelated ones, to become configuration inputs.

Two new options are now available to mitigate that. For simpler use cases, there are the Provider-based APIs to access [system properties](javadoc/org/gradle/api/provider/ProviderFactory.html#systemPropertiesPrefixedBy-java.lang.String-) or [environment variables](javadoc//org/gradle/api/provider/ProviderFactory.html#environmentVariablesPrefixedBy-java.lang.String-) with names starting with some prefix. Advanced processing, like filtering names with regular expression, can be done inside a custom [`ValueSource`](javadoc/org/gradle/api/provider/ValueSource.html) implementation. Reading a file, an environment variable, or a system property no longer adds a build configuration input inside the implementation of the `ValueSource`. The value of the `ValueSource` is recomputed each time the build runs, and the configuration cache entry is only invalidated if the value changes.

#### New compatible plugins and tasks

The [`kotlin-dsl`](userguide/kotlin_dsl.html#sec:kotlin-dsl_plugin) plugin is now compatible with the configuration cache.

The `dependencyInsight`, `outgoingVariants` and `resolvableConfigurations` tasks are now compatible with the configuration cache.

#### New `STABLE_CONFIGURATION_CACHE` feature flag

Working towards the stabilization of configuration caching we implement some strictness behind the `STABLE_CONFIGURATION_CACHE` feature flag when it is too disruptive for early adopters.

It is recommended to enable it as soon as possible in order to be ready for when we remove the flag and make the linked features enabled by default.

Learn more about what this feature flag enables in the [user manual](userguide/configuration_cache.html#config_cache:stable).

### JVM toolchains improvements

[Java toolchains](userguide/toolchains.html) provide an easy way to declare which Java version your project should be built with.
By default, Gradle will [detect installed JDKs](userguide/toolchains.html#sec:auto_detection) or automatically download new toolchain versions.

{'fraction_non_alphanumeric': 0.07962294424388287, 'fraction_numerical': 0.0047332531087043725, 'mean_word_length': 5.714516563425801, 'pattern_counts': {'":': 0, '<': 80, '<?xml version=': 0, '>': 80, 'https://': 64, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2968045', 'n_tokens_mistral': 6347, 'n_tokens_neox': 6107, 'n_words': 2842}