Table Of Contents

• Upgrade instructions
• New features and usability improvements
• Full Java 23 support
• Configuration cache improvements
• Build authoring improvements
• Preemptive warnings for outdated JVM versions in Gradle 9.0
• Matching specific vendors with daemon JVM criteria
• Promoted features
• Stable configuration options for the Java Gradle Plugin plugin
• Fixed issues
• Known issues
• External contributions
• Reporting problems

Upgrade instructions

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

./gradlew wrapper --gradle-version=8.10.1

See theGradle 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 thefull compatibility notes.

New features and usability improvements

Full Java 23 support

With this release, Gradle supports running onJava 23. This means you can now use Java 23 for thedaemon in addition totoolchains.

Note that certain features that rely on third-party tools, such asPMD andScala, may not work with Java 23 yet.

For details, see the fullcompatibility documentation.

Configuration cache improvements

Theconfiguration 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 theconfiguration cache can require updates to your build logic to meet compatibilityrequirements. When this feature is enabled, Gradle will report any incompatibilities via theConfiguration 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 tasksas 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 addedGradleLifecycle API is part of Gradle's core API and is used to manage and interact with a Gradle build's lifecycle events.

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

The issue is that the results ofGradleLifecycle.beforeProject{} execution are not observable within cross-project access API invocations, such asProject.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 newGradleLifecycle callbacks.

For example in:

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

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

The output is:

Lifecycle :rootAllprojects :rootFoo = barAllprojects :aFoo = nullAllprojects :bFoo = nullLifecycle :aLifecycle :b

Where the result of setting an extra property inGradleLifecycle.beforeProject{} is not observable inProject.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 thatGradleLifecycle.beforeProject{} is executed before mutable state access.

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

Lifecycle :rootAllprojects :rootFoo = barAllprojects :aLifecycle :aFoo = barAllprojects :bLifecycle :bFoo = bar

Otherwise, if only the project's immutable state is accessed, theGradleLifecycle.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 theupgrade 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

Thewebsite andvcsUrl properties ofgradlePlugin 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 seegradle.org/contribute.

Reporting problems

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

We hope you will build happiness with Gradle, and we look forward to your feedback viaTwitter or onGitHub.