Gradle Release Notes

Upgrade instructions

Switch your build to use Gradle 8.10.1 by updating the Wrapper in your project:

./gradlew wrapper --gradle-version=8.10.1

See the Gradle 8.x upgrade guide to learn about deprecations, breaking changes, and other considerations when upgrading to Gradle 8.10.1.

For Java, Groovy, Kotlin, and Android compatibility, see the full compatibility notes.

New features and usability improvements

Full Java 23 support

With this release, Gradle supports running on Java 23. This means you can now use Java 23 for the daemon in addition to toolchains.

Note that certain features that rely on third-party tools, such as PMD and Scala, may not work with Java 23 yet.

For details, see the full compatibility documentation.

Configuration cache improvements

The configuration cache improves build performance by caching the result of the configuration phase. Gradle uses the configuration cache to skip the configuration phase entirely when nothing that affects the build configuration has changed.

Reduced cache entry sizes and faster loading times

In Gradle 8.10, strings stored in the configuration cache are deduplicated at store time, meaning each unique string is written only once per file.

In addition to significantly reducing cache entry size, these changes have a significant impact on build performance when using configuration cache:

• With less data to encrypt/decrypt, execution times for cache-hit builds are reduced by around 28%, and for cache-miss builds by about 7%.
• Sharing strings reduces memory allocation by approximately 13% for cache-hit builds.

This is possible with string deduplication because less data needs to be written to and read from disk, and each string can be read once and then shared.

In general, larger and more complex builds benefit the most from these improvements.

The improvements are quantified with metrics from three different projects of varying sizes and complexities:

Small project (NowInAndroid, 33 modules)

Medium size project (Gradle, 184 modules)

Large project (Large Android build, 3400+ modules)

Enhanced Configuration Cache reporting

Adopting the configuration cache can require updates to your build logic to meet compatibility requirements. When this feature is enabled, Gradle will report any incompatibilities via the Configuration Cache report.

Report provides invalidation reason for cache misses

In Gradle 8.10, the Configuration Cache report now includes the invalidation reason in case of a cache miss, similar to the console output:

Report lists incompatible tasks

Since Gradle 7.4, it is possible to mark tasks as not compatible with the Configuration Cache. When these tasks participate in a build invocation, the cache entry will not be stored.

In Gradle 8.10, any incompatible tasks executed as part of the invocation are shown in a new dedicated section of the report:

Report is copy-paste friendly

Finally, the report content is copy-friendly in Gradle 8.10. Copying and pasting the description of problems now produces Markdown-like text that preserves meaningful indentations:

- [error] Project `:foo` cannot dynamically lookup a property in the parent project `:`
    - property `prop` of `:foo`
        - build file 'foo/build.gradle'

Build authoring improvements

Gradle provides rich APIs for plugin authors and build engineers to develop custom build logic.

Improved behavior and callback execution for the GradleLifecycle API

The recently added GradleLifecycle API is part of Gradle's core API and is used to manage and interact with a Gradle build's lifecycle events.

Previously, the GradleLifecycle.beforeProject{} callback was executed right before the project evaluation.

The issue is that the results of GradleLifecycle.beforeProject{} execution are not observable within cross-project access API invocations, such as Project.allprojects{}, Project.getAllprojects{}, Project.subprojects{}, etc. Some builds may depend on the eagerness of these APIs, necessitating additional build logic changes when migrating to the new GradleLifecycle callbacks.

For example in:

// settings.gradle.kts
gradle.lifecycle.beforeProject {
    println("Lifecycle :$name")
    extra["foo"] = "bar"    // Set project state
}
rootProject.name = "root"
include(":a")
include(":b")

// build.gradle.kts
allprojects {   // Eager cross-project access API
    println("Allprojects :$name")
    println("Foo = ${extra["foo"]}")    // Access project state
}

The output is:

Lifecycle :root
Allprojects :root
Foo = bar
Allprojects :a	
Foo = null
Allprojects :b
Foo = null
Lifecycle :a
Lifecycle :b

Where the result of setting an extra property in GradleLifecycle.beforeProject{} is not observable in Project.allprojects{}.

In this release, the behavior of this incubating API has changed. If the mutable state of the project is accessed in cross-project access APIs, the execution order will change, such that GradleLifecycle.beforeProject{} is executed before mutable state access.

Now, the result of running the above example would be:

Lifecycle :root
Allprojects :root
Foo = bar			
Allprojects :a
Lifecycle :a
Foo = bar
Allprojects :b
Lifecycle :b
Foo = bar

Otherwise, if only the project's immutable state is accessed, the GradleLifecycle.beforeProject{} callback will be executed in the previous order.

Preemptive warnings for outdated JVM versions in Gradle 9.0

Starting with Gradle 9.0, Gradle will require JVM 17 or newer to run. Gradle will still support compiling Java code to target JVM version 6 or later. For more details, see the upgrade guide.

With this release, Gradle will start emitting warnings when using older JVM versions:

Executing Gradle on JVM versions 16 and lower has been deprecated. This will fail with an error in Gradle 9.0. Use JVM 17 or greater to execute Gradle. Projects can continue to use older JVM versions via toolchains.

Matching specific vendors with daemon JVM criteria

Daemon JVM critiera supports specifying the JVM vendor. When considering available JVM toolchains, Gradle will only choose a toolchain compatible with both the specified JVM vendor and version.

If no JVM vendor is specified in the criteria, any vendor is considered compatible.

This feature is still incubating and may change in future versions of Gradle.

Promoted features

Promoted features are features that were incubating in previous versions of Gradle but are now supported and subject to backward compatibility. See the User Manual section on the “Feature Lifecycle” for more information.

The following are the features that have been promoted in this Gradle release.

Stable configuration options for the Java Gradle Plugin plugin

The website and vcsUrl properties of gradlePlugin extension are now stable.

Fixed issues

Known issues

Known issues are problems that were discovered post-release that are directly related to changes made in this release.

External contributions

We love getting contributions from the Gradle community. For information on contributing, please see gradle.org/contribute.

Reporting problems

If you find a problem with this release, please file a bug on GitHub Issues adhering to our issue guidelines. If you're not sure you're encountering a bug, please use the forum.

We hope you will build happiness with Gradle, and we look forward to your feedback via Twitter or on GitHub.