Gradle Release Notes

Upgrade instructions

Switch your build to use Gradle 9.5.0 by updating the wrapper in your project:

./gradlew wrapper --gradle-version=9.5.0 && ./gradlew wrapper

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

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

New features and usability improvements

Diagnostics and reporting improvements

Gradle provides built-in reporting tasks to help you understand and troubleshoot your build.

Task provenance in reports and failure messages

When a task fails, Gradle now includes provenance information in the error message, telling you whether the task was registered by a build script, settings script, or plugin, and which one. This helps you quickly locate the source of a failing task in complex builds with many plugins and subprojects:

Execution failed for task ':app:compileJava' (registered by plugin 'org.gradle.api.plugins.JavaPlugin').

Provenance is omitted from failure messages for verification failures (e.g., test failures), since those are expected outcomes rather than configuration issues.

In addition, the outputs of some reports have been enhanced with provenance information.

When running the help task with the --task argument, task provenance information will be printed:

> ./gradlew help --task processUrl

Detailed task information for processUrl

Path
     :processUrl (registered in build file 'build.gradle')

Type
     UrlProcess (UrlProcess)

When running the tasks report, there is now a --provenance option available that will display the same information:

> ./gradlew tasks --provenance

Build tasks
-----------
assemble - Assembles the outputs of this project. (registered by plugin 'org.gradle.language.base.plugins.LifecycleBasePlugin')
build - Assembles and tests this project. (registered by plugin 'org.gradle.language.base.plugins.LifecycleBasePlugin')

See Task Provenance to learn more.

Improved diagnostics for daemon JVM compatibility

When Gradle finds an existing daemon but cannot use it due to JVM incompatibility, it now logs the specific reason at the INFO level:

Found daemon DaemonInfo{pid=32935, ...} however its context does not match the desired criteria.
JVM is incompatible.
Wanted: DaemonRequestContext{jvmCriteria=.../corretto-1.8.0_412/... (no Daemon JVM specified, using current Java home), ...}
Actual: DefaultDaemonContext[javaHome=.../jdk-17.0.13+11/..., javaVersion=17, javaVendor=Eclipse Adoptium, ...]

Previously, Gradle only stated that a new daemon would be used without explaining why the existing one was rejected.

This makes it easier to diagnose unexpected daemon behavior, whether using --no-daemon, investigating daemon spawns, or troubleshooting JVM compatibility issues.

Core plugin and plugin authoring enhancements

Gradle provides a comprehensive plugin system, including built-in Core Plugins for standard tasks and powerful APIs for creating custom plugins.

Automatic retries for Wrapper downloads

The Gradle Wrapper now supports automatic retries when downloading the Gradle distribution. This helps reduce build failures caused by unstable network connections or temporary server issues. By default, retries are disabled to preserve existing behavior

To enable retries, add the following properties to gradle-wrapper.properties:

retries=3 # Sets the maximum number of retry attempts
retryBackOffMs=1000 # Sets the initial delay between retries (doubles on each failure)

See Configuring Wrapper Retries to learn more.

Type-safe accessors for precompiled Kotlin Settings plugins

Gradle now generates type-safe Kotlin accessors for precompiled Settings plugins (*.settings.gradle.kts), matching the experience already available for project-level precompiled script plugins.

Now, type-safe accessors are generated automatically, giving you IDE autocompletion and compile-time checking:

// build-logic/src/main/kotlin/my-settings-convention.settings.gradle.kts 
plugins {
   id("com.gradle.develocity")
}

// Type-safe accessors, just like in project plugins 
develocity {
   buildScan {
       publishing.onlyIf { false }
   }
}

To enable these accessors, ensure your convention plugin build includes the kotlin-dsl plugin:

// build-logic/build.gradle.kts
plugins {
    `kotlin-dsl`
}

Previously, when writing a precompiled script plugin for Settings, you often had to use string-based APIs to configure extensions or plugins:

// build-logic/src/main/kotlin/my-settings-convention.settings.gradle.kts
plugins {
    id("com.gradle.develocity")
}

// No accessors, string-based API required
extensions.configure<com.gradle.develocity.agent.gradle.DevelocityConfiguration> {
    buildScan {
        publishing.onlyIf { false }
    }
}

See the Gradle Kotlin DSL Primer to learn more.

Init Task supports specifying the project directory

The gradle init task now accepts an --into option to specify the target directory for the new project. The directory is created automatically if it doesn't exist:

gradle init --type java-application --into my-new-project

Previously, initializing a project in a new directory required creating it manually and either changing into it or using the global --project-dir flag:

mkdir my-new-project
cd my-new-project
gradle init

See Build Init Plugin to learn more.

Domain Object Collections can be made immutable

Domain Object Collections are the typed containers Gradle uses to manage groups of related build model elements (such as tasks, configurations, source sets, and custom objects contributed by plugins). Plugin authors can now lock Domain Object Collections to prevent further modifications using the new disallowChanges() method. For example, a plugin that populates a collection during configuration can lock it to prevent other plugins from adding unexpected elements or removing existing ones. This is also useful for preventing modifications after execution has started, when changes would no longer take effect:

• Once disallowChanges() is called, elements can no longer be added to or removed from the collection.
• Invoking this method does not force the realization of lazy items previously added to the collection.
• This lock applies only to the collection itself. Individual objects within the collection can still be modified.

val myCollection = objects.domainObjectContainer(MyType::class)
val main = MyType("main")

myCollection.add(main)
myCollection.add(MyType("test"))

myCollection.disallowChanges()    // the collection is now immutable
main.setFoo("bar")                // individual elements can still be modified

myCollection.add(MyType("other")) // this will fail
myCollection.remove(main)         // this will fail

See the Javadocs to learn more.

Build authoring improvements

Gradle provides rich APIs for build engineers and plugin authors, enabling the creation of custom, reusable build logic and better maintainability.

Explicit bind address for client-daemon and cross-daemon communication

Gradle now supports the GRADLE_DAEMON_BIND_ADDRESS environment variable to explicitly specify the network address used for client-daemon and cross-daemon communication. When set, Gradle skips auto-detection entirely and uses the provided address:

GRADLE_DAEMON_BIND_ADDRESS=192.168.1.10 ./gradlew build

Previously, Gradle always attempted to auto-detect the local bind address, selecting the loopback address or falling back to the wildcard address. This could fail in environments with specific network configurations such as multiple network interfaces, multiple TCP/IP stacks, and similar setups.

See Gradle Environment Variables to learn more.

General improvements

Gradle provides various incremental updates and performance optimizations to ensure the continued reliability of the build ecosystem.

Easier Develocity integration

Gradle users with access to a Develocity server can now generate a Build Scan without modifying their project configuration.

On the CLI, passing the following option will automatically publish a Build Scan to the passed-in Develocity server:

./gradlew --develocity-url https://develocity.example.com build

See Build Scan for details.

Grouped --help output

./gradlew --help (or ./gradlew -h) now organizes CLI options into logical sections rather than listing them in a single alphabetical block. The sections are: Built-in (help, version, status, stop), Execution, Configuration, Performance, Security, Diagnostics, Logging, and Develocity.

Previously, all options were listed alphabetically with no grouping, making it hard to find related options or discover what categories of flags were available. The new layout makes it easier to scan for what you need.

See CLI Debugging to learn more.

Tooling and IDE integration

Gradle provides Tooling APIs that facilitate deep integration with modern IDEs and CI/CD pipelines.

Tooling integration improvements

Tooling API clients can now access Gradle help and version information directly, the same way the Gradle CLI does. This allows IDEs and other tools to provide a more consistent user experience when interacting with Gradle.

For example, in IntelliJ IDEA, users can run --help and --version via the Execute Gradle task toolbar action.

Documentation and training

Documentation

User Manual

The Isolated Projects page has been significantly revised. If you are considering adopting this experimental feature, the updated documentation provides a comprehensive overview.

The samples page has been removed. Code examples can now be found on their corresponding documentation pages, with links to the repository for full project files. For reference, you can still view the original samples page from Gradle 9.4.1.

Training

The following course is now available: Dependency Management 1: Configurations

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 if 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.