Gradle Release Notes

Upgrade Instructions

Switch your build to use Gradle 6.8-milestone-2 by updating your wrapper:

./gradlew wrapper --gradle-version=6.8-milestone-2

See the Gradle 6.x upgrade guide to learn about deprecations, breaking changes and other considerations when upgrading to Gradle 6.8-milestone-2.

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

Performance improvements

Kotlin DSL script compilation is faster and consumes less memory

In this release, the compilation of Gradle Kotlin DSL scripts (*.gradle.kts) is faster and consumes less memory.

On a sample medium-sized build, the cumulative script compilation time goes from ~50 seconds down to ~21 seconds with cold caches and cold daemons. This improvement also reduces memory pressure. Garbage collection time goes from 2.6 seconds down to 1.3 seconds.

While the impact on your build may vary, most builds can expect a noticeably shorter feedback loop when editing Kotlin DSL build logic thanks to this improvement.

<<<<<<< HEAD

Compilation avoidance for Kotlin DSL scripts

Until now, any changes to build logic in buildSrc required all the build scripts in the project to be recompiled.

This release introduces compilation avoidance for Gradle Kotlin DSL scripts. This feature will cause the scripts to be recompiled only if a change to shared build logic impacts the ABI (application binary interface) of the resulting artifact. In simpler terms, changes to private implementation details of build logic, such as private methods or classes, bodies of non-private methods or classes, as well as internal changes to precompiled script plugins such as configuration of tasks will no longer trigger recompilation of the project's build scripts.

On a sample build with 100 subprojects, full recompilation of build scripts caused by a change in buildSrc can take ~20 seconds. A non-ABI change can eliminate build script recompilation altogether now, saving those 20 seconds.

While changes to buildSrc immediately affect the classpath of all the scripts, this improvement is more general and applies to changes in any jar on the scripts classpath that can be added by a plugin applied from an included build or added directly via buildscript {} block.

Improved cache hits when normalizing runtime classpaths

For up-to-date checks and the build cache, Gradle needs to determine if two task input properties have the same value. In order to do so, Gradle first normalizes both inputs and then compares the result.

Runtime classpath analysis now smartly inspects all properties files, ignoring changes to comments, whitespace, and differences in property order. Moreover, you can selectively ignore properties that don't impact the runtime classpath.

normalization {
    properties('**/build-info.properties') {
        ignoreProperty('timestamp')
    }
}

This improves the likelihood of up-to-date and build cache hits when any properties file on the classpath is regenerated or only differs by unimportant values.

See the userguide for further information.

Configuration cache improvements

Composite builds

Starting with this release, composite builds are fully supported with the configuration cache.

Supported core plugins

In this release a number of core Gradle plugins got improved to support the configuration cache:

• checkstyle
• pmd
• codenarc
• jacoco

See the matrix of supported core plugins in the user manual.

Dependency resolution improvements

Central declaration of repositories

Traditionally in a Gradle build, repositories used for dependency resolution are declared in every project. However, in most cases, the same repositories should be used in every project of a single build. This led to the common pattern of using an allprojects { ... } block to declare the repositories. In Gradle 6.8, this pattern can be replaced with a conventional block in settings.gradle(.kts):

dependencyResolutionManagement {
    repositories {
        mavenCentral()
    }
}

There are several advantages in using this new construct instead of using allprojects or repeating the declaration in every build script.

Learn more by reading how to declare repositories for the whole build.

Central declaration of component metadata rules

Component metadata rules are a powerful tool to fix bad metadata published on remote repositories. However, similarly to repositories, rules traditionnally had to be applied on each project. Starting from this release, it is possible to declare component metadata rules at a central place in settings.gradle(.kts):

dependencyResolutionManagement {
    components {
        withModule('com.google.guava:guava', GuavaRule)
    }
}

You can learn more about declaring rules globally in the user manual.

Consistent dependency resolution

It's a common problem that the dependencies resolved for the runtime have different versions than the dependencies resolved for compile time. This typically happens when a transitive dependency that is only present at runtime brings in a higher version of a first level dependency.

To mitigate this problem, Gradle now introduces an API which lets you declare consistency between dependency configurations. For example, in the Java ecosystem, you can write:

java {
    consistentResolution {
        useCompileClasspathVersions()
    }
}

which tells Gradle that the common dependencies between the runtime classpath and the compile classpath should be aligned to the versions used at compile time.

There are many options to configure this feature which are described in the user manual.

New features and usability improvements

Viewing all available toolchains

Gradle can now provide a list of all detected toolchains including their metadata. Output of gradle -q javaToolchains:

 + AdoptOpenJDK 1.8.0_242
     | Location:           /path/to/8.0.242.hs-adpt/jre
     | Language Version:   8
     | Is JDK:             true
     | Detected by:        SDKMAN!

 + OpenJDK 15-ea
     | Location:           /path/to/java/15.ea.21-open
     | Language Version:   15
     | Is JDK:             true
     | Detected by:        SDKMAN!

 + Oracle JDK 1.7.0_80
     | Location:           /Library/Java/jdk1.7.0_80.jdk/jre
     | Language Version:   7
     | Is JDK:             true
     | Detected by:        macOS java_home

This can help to debug which toolchains are available to the build, how they are detected and what kind of metadata Gradle knows about those toolchains. See the toolchain documentation for more in-depth information on toolchain detection and usage.

Implicit imports

When using dependency injection when developing plugins, tasks or project extensions, it is now possible to use the @Inject annotation without explicitly importing it into your build scripts the same way it works for other Gradle API classes.

Security Improvements

Outdated TLS versions are no longer enabled by default

This version of Gradle removes TLS protocols v1.0 and v1.1 from the default list of allowed protocols. Gradle will no longer fallback to TLS v1.0 or v1.1 by default when resolving dependencies. Only TLS v1.2 or TLS v1.3 are allowed by default.

These TLS versions can be re-enabled by manually specifying the system property https.protocols with a comma separated list of protocols required by your build.

The vast majority of builds should not need to change in any way. Maven Central and JCenter/Bintray dropped support for TLS v1.0 and TLS v1.1 two years ago. Java has had TLS v1.2+ available for several years. Disabling these protocols in Gradle protects builds from downgrade attacks.

Depending on the version of Java you use, Gradle will negotiate TLS v1.2 or TLS v1.3 when communicating with remote repositories.

Note: Early versions of JDK 11 & JDK 12 contained race condition bug in the TLSv1.3 handling logic which causes the exception javax.net.ssl.SSLException: No PSK available. Unable to resume. If you run into this issue, we recommend updating to the latest minor JDK version.

IDE integration

Importing projects with custom source sets into Eclipse

This version of Gradle fixes problems with projects that use custom source sets, like additional functional test source sets.

Custom source sets are now imported into Eclipse automatically and no longer require manual configuration in the build.

Promoted features

Promoted features are features that were incubating in previous versions of Gradle but are now supported and subject to backwards 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.

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.