Gradle 7.0 was released on 9th April 2021, and includes some important new features and improvements. Discover what’s new, and what the benefits could be for your Gradle project.

New features/improvements in Gradle 7

Java toolchain support

What is it?

Gradle’s new Java toolchain allows you to use different versions of Java for different parts of your build.

By default, Gradle uses the same Java version to compile and run your application as the version you’re using to run Gradle itself. With the Java toolchain you can ensure your project is always built using a specific version of Java. Gradle will detect the location of locally installed JDKs and even download them if necessary.

Currently the Java toolchain is supported for the following task types:

  • JavaCompile
  • JavaExec
  • Test
  • Javadoc

Technically speaking, the Java toolchain feature has been available since Gradle 6.7. In Gradle 7.0 it was promoted to a stable feature.

How will it help me?

You can ensure consistent results for your Gradle builds by ensuring that the same JDK version and optionally vendor are used wherever your build is run, whether that be on a developer’s workstation or CI server.

The toolchain can also help you create a multi-project build where different Java versions are used to compile each project. This could, for example, help you to incrementally migrate an application to a new Java version module-by-module.

Lastly, if for some reason you needed to build your production code with an older Java version, with the Java toolchain you can run your tests using a more recent version.

How do I use it?

With the java or java-library plugin applied to your project, you can configure the project-wide Java version like this:

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(15)

For more fine grained control per task, this can be achieved by setting the javaCompiler , javaLauncher, or javadocTool task property, depending on the type of task.

Here’s an example where we create a test task to run on Java 14:

task('testsOn14', type: Test) {
    javaLauncher = javaToolchains.launcherFor {
        languageVersion = JavaLanguageVersion.of(14)

For more examples and to try this new feature yourself, check out the accompanying GitHub repository.

Java 16 support

Java 16 was released on 16th March 2021, and includes new language features such as:

  • records - a new type of class for immutable data objects, reducing the amount of boilerplate code developers have to write
  • pattern matching for instanceof - when you write a if statement using the instanceof operator in the condition, the object will be available automatically within the if block as the specific type without requiring a cast

Gradle 7.0 now fully supports Java 16.

How will it help me?

You can now move to Java 16 within your Gradle project. You’ll then be in a good position to move to the new long-term support version when Java 17 is released in September 2021.

How do I use it?

You can run Gradle itself on Java 16 by setting the JAVA_HOME environment variable appropriately. Gradle will also compile and run your application with the same version. You can also use the Java toolchain support discussed above to be more specific about versions of individual parts of your build.

Java module support

What is it?

Java 9 introduced the module concept, aiming to overcome some of the limitations of the Java classpath by providing:

  • a way to encapsulate code in a consumable module
  • a way to describe dependencies between modules

Java modules allow developers to write more scalable software since boundaries between groups of classes can be more rigorously enforced, promoting cleaner code.

Gradle 7.0 provides support for compiling, testing, and executing Java modules. It automatically generates the --module-path argument for the Java compiler, telling it the location of any required modules.

How will it help me?

If you’re using Java modules in your application, you now have full support from Gradle.

One limitation to be addressed in future versions is the fact that if the dependencies in and build.gradle are not kept in sync no warnings are generated.

How do I use it?

Java module support is a promoted feature in Gradle 7.0, meaning it’s enabled by default.

  • the java-library plugin automatically detects if you have a file, and then builds your project as a module
  • the application plugin now allows you to configure the name of the module you want to run:

application { mainModule = ‘’ // name defined in mainClass = ‘com.tomgregory.sample.Main’ }

Groovy 3 support

What is it?

Released in 2020, Groovy 3 adds some significant language features, including:

  • Java-style lambda syntax e.g. ['South Park', 'Family Guy'].stream().filter(cartoon -> cartoon.startsWith('S'))
  • method and constructor references e.g. ['South Park', 'Family Guy'].stream().forEach( System.out::println )
  • Elvis assignment operator e.g. magicNumber ?= 62

Gradle 7 now uses Groovy version 3 instead of 2 for compiling build scripts.

How will it help me?

You’ll benefit from all these new Groovy language features in your build scripts.

How do I use it?

Groovy 3 will be used to compile your build scripts as soon as you upgrade to Gradle 7.0. You may encounter these breaking changes since Groovy 3 is not backwards compatible with Groovy 2.

Native support for Apple Silicon

What is it?

Apple Silicon is the new range of processors for Mac computers based on the ARM64 architecture. This architecture will be replacing the Intel x86-64 architecture used previously.

JDKs are available specifically designed to support the ARM64 architecture. From Gradle 7.0 onwards, these JDKs are fully supported with all features.

How will it help me?

If you’re using Apple Silicon, then Gradle features which were disabled before are now enabled e.g. rich console and file system watching.

How do I use it?

If you’re using an ARM64 JDK then full support will be enabled by default as soon as you upgrade to Gradle 7.0.

File system watching

What is it?

During a developer’s standard workflow, they may execute the same Gradle task multiple times in a row. Gradle has to determine whether the inputs and outputs of the task have been updated.

  • if the inputs/outputs have been updated, the task must be rerun
  • if the inputs/outputs are the same as the previous execution, the task is marked as up-to-date

For example, imagine that within a Java Gradle project you run the assemble task multiple times. This task depends on compileJava, whose inputs are the Java source files and outputs are the compiled classes. In order for Gradle to keep track of whether compileJava must be rerun between task executions, it has to check for changes to the Java source files and the compiled classes.

This constant reloading of the filesystem into what Gradle calls the Virtual File System (VFS) is an expensive process, since the VFS must be loaded for every build. File system watching allows this information to be kept in memory within the Gradle daemon, and updated automatically through notifications of file system updates from the operating system.

This all means that to determine if a task needs to be executed disk I/O is minimised, reducing build time.

How will it help me?

Gradle report that during their own testing file system watching reduced build time by 20%. The improvements are most significant for incremental builds, where small changes are being made between task executions.

How do I use it?

This feature is now enabled by default in Gradle 7.0.

It works in Windows, Mac, and Linux environments, and supports many file system types (see the full list).

Other notable changes



For a complete list of all the changes consult the Gradle 7.0 Release Notes.


Check out the accompanying video from the Gradle Hero YouTube channel.