Gradle Release Notes

Upgrade instructions

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

./gradlew wrapper --gradle-version=8.11.1

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

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

New features and usability improvements

Configuration Cache improvements

Gradle's 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.

Faster Configuration Cache with parallel load and store

When enabled, the Configuration Cache can greatly increase build performance. However, for large and complex builds, storing and loading cache entries can still incur a noticeable overhead.

To address this, storing and loading of the Configuration Cache can now be performed in parallel, resulting in better performance in case of both cache misses and hits.

To enable the feature, add the following flag in gradle.properties:

org.gradle.configuration-cache.parallel=true

This is an incubating feature and may expose concurrency issues in some builds.

For more details on configuring parallel caching, see Configuration Cache.

Configuration Cache enabled by default when using the Build Init plugin

The Configuration Cache has been stable since Gradle 8.1 and is already widely used. As we work towards making it the preferred mode of execution, we continue to encourage further adoption.

Starting with this release, projects generated by the Build Init plugin enable the Configuration Cache via the root gradle.properties file. This also includes projects converted from Maven.

Configuration Cache compatibility for C++ and Swift plugins

Most core plugins and Gradle features are already compatible with Configuration Cache. This release also addresses the compatibility of native plugins.

The following C++ and Swift plugins are now Configuration Cache compatible:

• Swift application
• Swift library
• XCTest
• C++ application
• C++ library
• CppUnit
• GoogleTest
• Visual Studio
• XCode

Error and warning reporting improvements

Gradle provides a rich set of error and warning messages to help you understand and resolve problems in your build.

The new Problems API is getting integrated across more Gradle core components, providing more structured and consistent error reporting, helping to make error reporting cleaner and more actionable.

Improved Java compilation task failure reporting

In previous Gradle versions, finding the reason for a failed Java compilation was not always easy. In case of long build output, users typically had to scroll back and manually locate the failed task's output where the compiler error details could be found. Using the --continue flag further complicated discovery, making it challenging to identify the exact failure.

In this release, Java compilation warning and errors are summarized during task execution and at the end of the build log.

A Java compilation failure at the bottom of the log will show up as:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':project1:compileJava'.
> Compilation failed; see the compiler output below.

  sample-project/src/main/java/Problem.java:6: error: incompatible types: int cannot be converted to String
          String a = 1;
                     ^

If any Java compilation warnings are discovered during the compilation, they will be included in the error message as well:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':project1:compileJava'.
> Compilation failed; see the compiler output below.

  sample-project/src/main/java/Problem1.java:6: warning: [cast] redundant cast to String
          var warning = (String)"warning";
                        ^
  sample-project/src/main/java/Problem2.java:6: error: incompatible types: int cannot be converted to String
          String a = 1;
                     ^

Note that the current solution reports upon Java compilation failures. If only warnings occur (and no -Werror is set), they will not be repeated at the end of the build.

This feature also works with the --continue flag, and the bottom report will contain a per-task message of all the compilation failures.

Consolidated report for warnings and deprecations

Deprecation and other warnings are now presented in a rich report generated at the end of the build. This report serves as a central location for users to review problems that occurred during a build.

Plugin authors can use the Problems API to log events specific to their plugins, adding to the Gradle-generated ones.

The report is not generated if no issues have been reported. Also, if you do not want to generate this report, you can disable it with the --no-problems-report flag.

The console output provides a link to this report, as shown below:

[Incubating] Problem report is available at: <project-dir>/build/reports/problems/problems-report.html

BUILD SUCCESSFUL in 1s

The rendered report link directs you to a detailed HTML view of the problems, such as:

Build authoring improvements

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

Root variant exposed by the Resolution Result API

The ResolutionResult API, which contains the results of dependency resolution, now exposes the root variant of the resolved graph in addition to its owning component.

Previously, the API only exposed the root component, which exposed the first-level dependencies as well as dependencies from other selected variants in the root component:

val rootComponent = configurations.runtimeClasspath.incoming
    .resolutionResult.rootComponent

In this release, the root variant is also exposed. The root variant is a synthetic variant representing the Configuration being resolved, and exposes the first-level dependencies of a resolution:

val rootVariant = configurations.runtimeClasspath.incoming
    .resolutionResult.rootVariant

The updated API allows for more precise traversal of dependency graphs by operating at the variant level instead of the component level. For example, traversing dependencies at the variant level allows users to differentiate between a component's production code and its test fixtures.

For more details on how to perform a graph traversal, see Programmatic Dependency Resolution.

API for selecting variants by feature name

Using the requireCapability API, Gradle allows variants of a target component to be selected based on the group and name of the variant's capability. This functionality is used to select "features" of a target component, such as a library's test fixtures. However, this API can be difficult to use when targeting a project dependency, as the group and name of the target project are not known when declaring a project dependency.

Gradle 8.11 introduces a new requireFeature API that is specifically tailored for selecting variants of a target component using the feature name. Selecting a capability by feature name is equivalent to requesting a capability with the following form: ${project.group}:${project.name}-${featureName}.

For example, if we have a java-library project that registers a feature using the registerFeature API:

plugins {
    id("java-library")
}


java {
    registerFeature("foo") {
        usingSourceSet(sourceSets.create("foo"))
    }
}

We can depend on that feature using the requireFeature API:

plugins {
    id("java-library")
}


dependencies {
    implementation(project(":other")) {
        capabilities {
            requireFeature("foo")
        }
    }
}

Introduced project path accessor on ProjectDependency

This release introduces ProjectDependency#getPath() for accessing the identity of the target of a project dependency.

Native toolchains support

Gradle's native toolchain support enables building C/C++ projects with compilers like GCC, Clang, and Visual C++.

Linux arm64 as a build target

This release adds Clang and GCC support to Gradle on Linux platforms that use the ARM or AArch64 architecture.

Thank you to Matthew Von-Maszewski for the contribution.

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 Build Features API

The BuildFeatures API is now stable. It allows users to check the status of Gradle features such as configurationCache and isolatedProjects.

Stable methods in ProviderFactory API

The following methods of the ProviderFactory are now stable:

• exec
• javaexec
• environmentVariablesPrefixedBy(String)
• environmentVariablesPrefixedBy(Provider)
• gradlePropertiesPrefixedBy(String)
• gradlePropertiesPrefixedBy(Provider)
• systemPropertiesPrefixedBy(String)
• systemPropertiesPrefixedBy(Provider)

The ExecOutput and ExecOutput.StandardStreamContent interfaces are now stable too.

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.