The Gradle team is excited to announce Gradle 7.1.1.
This release revamps incremental Java compilation and makes it easier to configure Groovy, Scala and Antlr sourcesets in Kotlin DSL.
There are also several new deprecations and small improvements to make Gradle easier to use.
We would like to thank the following community members for their contributions to this release of Gradle:
Danny Thomas, Roberto Perez Alcolea, Victor Merkulov, Kyle Moore, Stefan Oehme, Anže Sodja, Jeff, Alexander Likhachev, Björn Kautler, Sebastian Schuberth, Kejn, xhudik, Anuraag Agrawal, Florian Schmitt, Evgeny Mandrikov, Ievgenii Shepeliuk, Sverre Moe.
Switch your build to use Gradle 7.1.1 by updating your wrapper:
./gradlew wrapper --gradle-version=7.1.1
See the Gradle 7.x upgrade guide to learn about deprecations, breaking changes and other considerations when upgrading to Gradle 7.1.1.
NOTE: Gradle 7.1 has had one patch release, which fixes several issues from the original release. We recommend always using the latest patch release.
For Java, Groovy, Kotlin and Android compatibility, see the full compatibility notes.
Gradle has a Java incremental compiler enabled by default that makes incremental builds faster by only compiling Java source files that need to be compiled.
The Java incremental compiler received substantial improvements in this release.
In previous Gradle releases, incremental compilation analysis was only stored locally. This meant that when the compile task's outputs were fetched from the build cache, a subsequent build could not do incremental compilation and always required a full recompilation.
In Gradle 7.1, the result of incremental analysis is now stored in the build cache and the first compilation after fetching from the build cache will be incremental.
Incremental compilation analysis requires Gradle to extract symbols from class files and analyze a transitive graph of dependencies to determine the consumers of a particular symbol. This can consume lots of memory and time.
Gradle 7.1 significantly reduces the cost of incremental compilation analysis, as well as the size of the analysis.
The impact of this change will vary by project but can be very noticeable. On the Gradle project itself, we were able to make incremental compilation up to twice as fast!
Lastly, because of the way the Java compiler works, previous Gradle releases were forced to perform a full recompilation as soon as any constant was changed in an upstream dependency.
Gradle 7.1 introduces a compiler plugin that performs constant usage tracking, and only recompiles the consumers of constants when those constants change.
This can speedup incremental builds for projects using lots of constants, which is common for generated code from template engines.
When using the Kotlin DSL, a special construct was required when configuring source locations for languages other than Java. For example, here's how you would configure groovy sources:
sourceSets {
main {
withConvention(GroovySourceSet::class) {
groovy {
setSrcDirs(listOf("src/groovy"))
}
}
}
}
Gradle 7.1 defines an extension to source sets for each language in the following plugins:
groovyantlrscalaThis means that the Kotlin DSL will have access to auto-generated accessors and withConvention is no longer necessary:
sourceSets {
main {
groovy {
setSrcDirs(listOf("src/groovy"))
}
}
}
When declaring arguments for a compiler daemon using jvmArgs, these arguments are always treated as String inputs to the compile task.
Sometimes these arguments represent paths to files that need to be captured as part of the build cache key. Modeling these arguments as input files can improve the incrementality of the compile task and avoid unnecessary cache misses.
Previously, arguments for the Java compiler invocation could be declared in a using compiler argument providers, but there was no way to do this for the command-line arguments to the compiler daemon process itself. You can now provide command-line arguments to the compiler daemon for JavaCompile, GroovyCompile, and ScalaCompile tasks using jvmArgumentProviders.
CommandLineArgumentProvider objects configured via jvmArgumentProviders will be interrogated for input and/or output annotations and Gradle will add these to the respective task.
def javaAgent = objects.newInstance(JavaAgent)
javaAgent.jarFile = file('some/path/to/agent.jar')
// This can be done with Groovy, Java or Scala compilation
tasks.withType(GroovyCompile).configureEach {
groovyOptions.forkOptions.jvmArgumentProviders.add(javaAgent)
}
abstract class JavaAgent implements CommandLineArgumentProvider {
@Classpath
abstract RegularFileProperty getJarFile()
@Override
List<String> asArguments() {
def jarFilePath = jarFile.get().asFile.absolutePath
return ["-javaagent:${jarFilePath}".toString()]
}
}
The JaCoCo plugin has been upgraded to the most recent JaCoCo version 0.8.7 which includes support for Java 15 and 16 and experimental support for Java 17.
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.