Gradle 7.0 improves incremental builds, backs Java 16

Gradle 7.0, the latest release of the popular software build tool leveraged in Android development and elsewhere, offers faster incremental builds as well as support for Java 16.

With the Gradle 7.0 release, introduced April 9, file system watching is enabled by default, to make incremental builds quicker. The capability was introduced as an opt-in feature in Gradle 6.5 and deemed production-ready in Gradle 6.7.

When file system watching is enabled, Gradle maintains what it has learned about the file system in memory between builds and skips reading from the file system on each build. With an incremental build, input and output files are checked to find out what needs to be rebuilt. This capability usually saves a lot of time but adds some I/O overhead, which can be noticeable in large projects when not much has changed since the prior build.

To upgrade to Gradle 7.0, developers can update their wrapper:

./gradlew wrapper --gradle-version=7.0

Developers can access the Gradle upgrade guide and compatibility notes to learn about breaking changes, deprecations, and other considerations.

Also in Gradle 7.0:

• For Android, performance has been improved for incremental changes in projects, especially those using the Jetifer tool to migrate libraries.
• Gradle now supports running on and building with Java 16, or Java Development Kit (JDK) 16, which was released on March 16. To support JDK 16, Gradle has been upgraded to use the Groovy 3 language in Groovy DSL build scripts.
• Native support is offered for Apple Silicon systems, with every feature now supported using a native Arm JDK. Previous Gradle versions could run on Apple Silicon Macs but there were disadvantages, such as some Arm JDK features had to be disabled while an Intel JDK would run at about half speed through the Rosetta2 compatibility layer.
• Version catalogs are introduced as an experimental capability, enabling build authors to centralize dependency coordinates (group, artifact, versions) of their third-party dependencies in a conventional configuration file and declare dependencies in a type-safe way.
• An experimental feature for project assessors provides type safety and enables code completion in IDEs.
• Build reliability improvements have been made, such as now executing a task without the benefit of parallel execution if a task is failing input/output validation.
• Dependency locking, a mechanism to ensure reproducible builds when using dynamic dependency versions, has been improved. The release defaults to the improved dependency locking file format that results in fewer lock files in most projects.