Gradle 8.10.2 is the second patch release for Gradle 8.10.

It fixes the following issues:

#30472 Investigate possibly broken 8.10.1
#30477 Kotlin Mutliplatform build with reused daemon fails with “Cannot query the value of task ‘:compileKotlinWindows’ property ‘kotlinNativeBundleBuildService’ because it has no value available.”
#30497 DefaultTaskCollection#configureEach(Action) on task set cannot be executed in the current context

Issues fixed in the first patch release:

#30239 Gradle 8.10 Significantly Slower Due to Dependency Resolution
#30272 Broken equals() contract for LifecycleAwareProject
#30385 Gradle should not validate isolated projects when isolated projects is disabled

We recommend users upgrade to 8.10.2 instead of 8.10.

Gradle now supports running on Java 23.

This release introduces performance and reporting improvements to the configuration cache, including a significant reduction in the cache file size and accelerated cache loading times. There are also updates to build authoring APIs.

Starting with Gradle 9.0, Gradle will require JVM 17 or newer to run. In Gradle 8.10, warnings will be emitted when running on older JVM versions.

We would like to thank the following community members for their contributions to this release of Gradle: Björn Kautler, Craig Andrews, gotovsky, Jeff, Kirill Gavrilov, Madalin Valceleanu, Sergei Vorobev, Thach Le, Thad Guidry

Be sure to check out the public roadmap for insight into what’s planned for future releases.

Upgrade instructions
New features and usability improvements
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.2 by updating the Wrapper in your project:

./gradlew wrapper --gradle-version=8.10.2

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

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)

Release	Cache-Hit Configuration Time	Cache-Miss Configuration Time	Storage	Memory allocations
8.9	295.87ms	2,297.11ms	12M	257.75M
8.10	226.46ms	2,233.88ms	5.2M	241.62M
Improvement	-23.46%	-2.75%	-57.4%	-6.3%

Medium size project (Gradle, 184 modules)

Release	Cache-Hit Configuration Time	Cache-Miss Configuration Time	Storage	Memory allocations
8.9	2,299.77ms	16,033.74ms	131M	1.48G
8.10	1,567.09ms	14,474.11ms	17M	1.21G
Improvement	-31.86%	-9.73%	-86.9%	-18.1%

Large project (Large Android build, 3400+ modules)

Release	Cache-Hit Configuration Time	Cache-Miss Configuration Time	Storage	Memory allocations
8.9	24,547.75ms	130,060.61ms	1.3G	18.55G
8.10	17,652.50ms	120,083.64ms	372M	15.97G
Improvement	-28.09%	-7.67%	-72.6%	-13.9%

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'

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

3 issues have been fixed in Gradle 8.10.2.

[#30497] - DefaultTaskCollection#configureEach(Action) on task set cannot be executed in the current context since 8.10.1
[#30477] - Kotlin Mutliplatform build with reused daemon fails with “Cannot query the value of task ‘:compileKotlinWindows’ property ‘kotlinNativeBundleBuildService’ because it has no value available.”
[#30472] - Investigate possibly broken 8.10.1

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.

Table Of Contents