Gradle Release Notes

Upgrade instructions

Switch your build to use Gradle 6.3 by updating your wrapper:

./gradlew wrapper --gradle-version=6.3

See the Gradle 6.x upgrade guide to learn about deprecations, breaking changes and other considerations when upgrading to Gradle 6.3.

For Java, Groovy, Kotlin and Android compatibility, see the full compatibility notes.

Support for Java 14

Gradle now supports running and building with Java 14.

Improved error messages

User-friendlier reporting of Gradle startup failures

When Gradle fails to start due to an internal service initialization failure, the error message will point to the root cause of the issue, for example:

Show location of Java fatal error log

When the Java virtual machine executing the Gradle daemon crashes unexpectedly, the Java virtual machine will generate a fatal error log. The crash could be due to a bug in Java, Gradle itself, or in the user code being executed.

Since it may be hard to find where this error log is written, Gradle now prints the location of the crash log to the console.

For example, in the following crash, the JVM fatal error log was written into /home/user/project/hs_err_pid11783.log:

Customizing location of native headers generated from Java source

The Java native keyword allows declaring methods that are implemented in native languages such as C or C++. The Java compiler can then generate native headers that should be implemented. It is most commonly used with Java Native Interface (JNI).

In previous releases, it was possible to configure the header output directory but it had no default value, so you had to configure it if you wanted to use JNI. In this release, there is a default value for the compile task for each source set so you don’t need to any more. If you had a custom header location set before, it is advised to remove it and just use the default value.

Please see the DSL guide for more details.

Improvements for plugin authors

Improvements for component metadata rules

Every module that is pulled from a repository has metadata associated with it, such as its group, name, and version. Sometimes, this metadata can be incomplete or incorrect. To manipulate such incomplete metadata from within the build script, Gradle offers an API to write component metadata rules.

The API for component metadata rules has been extended to allow access to packaging, classifier and type information from POM metadata.

The packaging information for a direct dependency can be obtained from the ComponentMetadataContext.

Additionally, ComponentMetadataRules can react on the classifier and type information of dependencies:

class ClassifierExampleRule implements ComponentMetadataRule {
    void execute(ComponentMetadataContext context) {
        context.details.allVariants {
            withDependencies {
                it.each { dependency ->
                    def classifier = 
                        dependency.artifactSelectors[0]?.classifier
                    ...
                }
            }
        }
    }
}

Fixed issues

Known issues

Known issues are problems that were discovered post release that are directly related to changes made in this release.

External contributions

We love getting contributions from the Gradle community. For information on contributing, please see gradle.org/contribute.

Reporting problems

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.