Improved incremental builds in Gradle 7.0

The most recent version of the well-known software build tool used in Android development and other areas, Gradle 7.0, provides support for Java 16 and faster incremental builds.

To speed up incremental builds, file system watching is now enabled by default in the Gradle 7.0 version, which was released on April 9. Gradle 6.5 offered the functionality as an opt-in feature, and Gradle 6.7 declared it production-ready.

When file system watching is enabled, Gradle keeps its knowledge of the file system in memory between builds instead of reading it during each build. The input and output files are examined during an incremental build to determine what needs to be rebuilt. The I/O overhead added by this capability, which typically saves a significant amount of time but also adds some, can be felt in large projects when little has changed since the previous 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.