The Gradle team is excited to announce Gradle 6.8-milestone-1. The Gradle team is excited to announce Gradle 6.8-milestone-1.
We would like to thank the following community contributors to this release of Gradle:
Jeff.
Switch your build to use Gradle 6.8-milestone-1 by updating your wrapper:
./gradlew wrapper --gradle-version=6.8-milestone-1
See the Gradle 6.x upgrade guide to learn about deprecations, breaking changes and other considerations when upgrading to Gradle 6.8-milestone-1.
For Java, Groovy, Kotlin and Android compatibility, see the full compatibility notes.
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.
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.
In this release a number of core Gradle plugins got improved to support the configuration cache:
See the matrix of supported core plugins in the user manual.
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.
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 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.
Known issues are problems that were discovered post release that are directly related to changes made in this release.
We love getting contributions from the Gradle community. For information on contributing, please see gradle.org/contribute.
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.