Gradle Release Notes

The Gradle team is excited to announce Gradle 8.2-rc-1.

Kotlin DSL continues to receive substantial improvements. The new reference documentation makes Kotlin DSL easier to understand. Also, simple property assignment with the = operator introduced to Kotlin DSL in the last release is now enabled by default. Finally, Kotlin DSL is now the default option when generating a new project with the init task.

This release also brings a number of usability improvements including better error messages, automated validation of distribution URL in the wrapper task, progress display for discovery of Java toolchains, more efficient dependency verification and more.

We would like to thank the following community members for their contributions to this release of Gradle: Bruno Didot, Eric Vantillard, esfomeado, Jendrik Johannes, Jonathan Leitschuh, Lee Euije, Stefan Oehme, Todor Dinev, Yanshun Li

Table Of Contents

Upgrade instructions

Switch your build to use Gradle 8.2-rc-1 by updating your wrapper:

./gradlew wrapper --gradle-version=8.2-rc-1

See the Gradle 7.x upgrade guide to learn about deprecations, breaking changes and other considerations when upgrading to Gradle 8.2-rc-1.

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

New features and usability improvements

Kotlin DSL improvements

Gradle's Kotlin DSL provides an enhanced editing experience in supported IDEs compared to the traditional Groovy DSL — auto-completion, smart content assist, quick access to documentation, navigation to source, and context-aware refactoring.

Kotlin DSL has received substantial improvements in the recent releases, leading to the announcement that Kotlin DSL is Now the Default for New Gradle Builds. This release brings another series of improvements.

Kotlin DSL reference

A brand new reference documentation for the Gradle Kotlin DSL is now published and versioned alongside the user manual.

You can use the Kotlin DSL reference search functionality to drill through the APIs.

Simple property assignment in Kotlin DSL enabled by default

The last release introduced the simpler way to assign values to lazy property types in Kotlin scripts using the = operator instead of the set() method. This new assignment operator is now available by default.

This feature is still incubating. In case of any issues you can opt-out by adding to the file.

For more information see Kotlin DSL Primer.

Gradle init defaults to the Kotlin DSL

Starting with this release, generating a new project with the gradle init command now defaults to using the Kotlin DSL instead of Groovy DSL.

In interactive mode you can choose which DSL to use and the Kotlin one is now listed first:

Select build script DSL:
  1: Kotlin
  2: Groovy
Enter selection (default: Kotlin) [1..2]

See the build init user manual chapter for more information.

Fail on script compilation warnings

Gradle Kotlin DSL scripts are compiled by Gradle during the configuration phase of your build. Deprecation warnings found by the Kotlin compiler are reported on the console when compiling the scripts.

In order to catch potential issues faster, it is now possible to configure your build to fail on any warning emitted during script compilation by setting the org.gradle.kotlin.dsl.allWarningsAsErrors Gradle property to true:


More details can be found in the dedicated section of the Kotlin DSL user manual chapter.

Improved console output

In the new release, we have taken the first step towards implementing the clean and actionable error reporting item from our public roadmap, by making a number of improvements to the console output in case of build failures.

Suggestions that were previously a part of the error message are now displayed in the * Try section, making them more noticeable. Additionally, the output is streamlined by eliminating unnecessary links to for recoverable errors, such as compilation failures.

You can review the complete list of these console output enhancements here.

Wrapper task validates distribution URL

The Gradle Wrapper stores the URL of Gradle distribution in the file.

Previously, specifying an invalid URL led to I/O exceptions during the build execution.

Starting from this release, the wrapper task automatically validates the configured distribution URL before writing it to the file. This surfaces invalid URLSs early and prevents exceptions at execution time.

More details can be found in the dedicated section of the Gradle Wrapper user manual chapter.

Java toolchains discovery progress display

Using Toolchains is a recommended way of specifying Java versions for JVM projects.

Progress is now displayed during Java toolchains discovery.

This can be especially useful during a cold-start of Gradle for users who have environments with a lot of JVM installations in them.

Dependency verification improvements

To mitigate the security risks and avoid integrating compromised dependencies in your project, Gradle supports dependency verification.

Exported PGP keys are now stripped to contain only necessary data. This feature can significantly reduce the size of the keyring files.

In addition, the exported keyring is sorted by key id and de-duplicated to ensure a consistent ordering of keys, which minimizes potential conflicts when updating the keyring.

In order to benefit from these changes, users will have to generate again their keyring.

Boolean task options generate opposite option

Task options of type boolean, Boolean, and Property<Boolean> now automatically generate an opposite option to make setting the value to false easier in the command-line interface.

This feature lets you conveniently set the Boolean option to false, simply by using the --no- prefix. For example, --no-foo option is generated for the provided option --foo.

See the task options user manual section for more information.

Built init can convert more Maven builds

Using gradle init to convert a multimodule Maven build previously required the child submodule projects’ POMs to reference their parent POM using:


Without these backreferences, the conversion process would fail.

The process has been updated to succeed also when the parent element is absent from the submodules.

Configuration API improvements

Using the Configuration API is a fundamental piece of writing Gradle builds. This is a large and multipurpose API that is easy to accidentally misuse. This release of Gradle will provide additional feedback if configurations are used inconsistently.

Call time configuration usage checking

Certain methods in the Configuration API should only be called when the configuration is in a particular “role” as determined by the isCanBeResolved()/isCanBeConsumed()/isCanBeDeclared() flags. For example, calling shouldResolveConsistentlyWith(Configuration) should only be done on a resolvable Configuration. Calling a method that is not appropriate for a configuration’s current role will now in many cases emit a deprecation warning.

These proper usages are now mentioned on the Configuration type’s javadoc.

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

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.