# Gradle Release Notes

We are excited to announce Gradle 9.5.0-20260409020231+0000 (released 2026-04-09).

This release improves diagnostics and reporting with task provenance in errors and reports, plus clearer logging when the client JVM is incompatible with daemon requirements.

Plugin authors gain type-safe Kotlin accessors for precompiled Settings convention plugins and automatic retry support for Wrapper downloads.

Build authoring is enhanced with the ability to lock Domain Object Collections and a new environment variable to specify the network address used for client-daemon communication.

Other improvements include additional `gradle init` option, easier Develocity integration, and grouped `--help` output. Finally, the Tooling API now exposes help and version information.

We would like to thank the following community members for their contributions to this release of Gradle: atm1020, mataha, Adam, Attila Kelemen, Benedikt Ritter, Björn Kautler, Caro Silva Rode, CHANHAN, Dmitry Nezavitin, Eng Zer Jun, KugelLibelle, Madalin Valceleanu, Markus Gaisbauer, Oliver Kopp, Philip Wedemann, ploober, Roberto Perez Alcolea, Rohit Anand, Suvrat Acharya, Ujwal Suresh Vanjare, Victor Merkulov

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

## Table Of Contents

## Upgrade instructions

Switch your build to use Gradle 9.5.0-20260409020231+0000 by updating the wrapper in your project:

    ./gradlew wrapper --gradle-version=9.5.0-20260409020231+0000 && ./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-20260409020231+0000.

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 the tasks and help --task have been enhanced with that same provenance information:

    > ./gradlew help --task processUrl

    Detailed task information for processUrl

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

    Type
         UrlProcess (UrlProcess)

The tasks list now supports a `--provenance` option that shows where each task was registered:

    > ./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, no retries are attempted.

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.

### Build authoring improvements

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

#### 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 and build authors can now lock Domain Object Collections to prevent further modifications using the new `disallowChanges()` method:

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

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