{{announcement.body}}
{{announcement.title}}

Gradle 5.6 Update: Making Groovy Compilation Faster

DZone 's Guide to

Gradle 5.6 Update: Making Groovy Compilation Faster

These new features and enhancements are totally groovy, man.

· Java Zone ·
Free Resource

Groovy enhancements

These new features and enhancements are totally groovy, man.

In this post, we will learn about the enhancements of about Gradle 5.6.

You may also like:  Groovy: A Retrospective

1. The Exit of Leaking Authentication Data

It was found that authentication data may leak while using the Gradle build tool to resolve dependencies against the custom authenticated repository. Officials are unaware of anyone having exploited the flaw, and thus, you should definitely upgrade the version since the features causing this issue are within the codebase and hard to disable.

2. Faster Groovy Compilation

This update has two latest features that help boost speed of Groovy compilation — Groovy compilation avoidance and incremental Groovy compilation.

Groovy compilation avoidance is the experimental feature that accelerates things by avoiding recompiling dependent projects if they don’t have anything that affects their output changed.

Incremental compilation means that if only small numbers of Groovy source files have been changed, only the affected source files are recompiled. Gradle doesn’t have to recompile every Groovy test source file. It will recompile only the changed classes and the classes affected by the changes.

3. Test Fixtures for Java Projects

Gradle 5.6 has a new Java test fixtures plugin that can be used along with Java or Java library plugin to create a traditional test fixtures source set. Gradle will run automated wiring so that test compilation depends on test fixtures. More significantly, the text fixtures plugin enables other projects to rely on the test fixtures of the project.

dependencies {

// this will add the test fixtures of "my-lib" on the compile classpath of the tests of _this_ project

testImplementation(testFixtures(project(":my-lib")))

}


4. Central Management of Plugin Versions With Settings Script

Gradle 5.6 makes central management of plugin versions simpler. Build scripts can us plugins through the plugins' {}  block without specifying a version by configuring all plugin versions in a setting script inside the latest pluginManagement.plugin {}  block.

pluginManagement {

plugins {

id 'org.my.plugin' version '1.1'

}

}


The block pluginManagement.plugins {} doesn’t have the same constrained syntax as a block of build script plugins' {}. These versions may be included from gradle.properties, or defined programmatically.

5. Better Performance for Big Projects on Windows

On the Windows platform, bigger projects encounter a significant performance decrease in Java compilation while shifting from the Java to the Java-library plugin. This usually happens due to a large number of class files on the classpath.

You can now command java-library plugin to use jars over class folders on the compile classpath. This can be done by setting the org.gradle.java.compile-classpath-packaging system property to true.

6. Enhanced Handling of ZIP Archives on Classpaths

It is now possible to detect the most common zip extension instead of only supporting .jar with compile classpath and runtime classpath analysis.

Gradle 5.6 will check nested ZIP archives also instead of taking them as blobs. This will enhance the likelihood of build-cache hits for tasks that consider such nested zips as input. For instance, testing apps packaged as a fat jar.

ZIP analysis also neglects unpacking irrelevant entries, for instance, resource files on a compile classpath. This enhances performance for projects with a vast number of resource files.

7. Support for PMD Incremental Analysis

The PMD plugin allows using PMD’s incremental analysis cache that helps in enhancing performance when files have not changed between builds. You can add the following code to your PMD configuration to enable incremental analysis:

pmd {

incrementalAnalysis = true

}


8. Executable Jar Support With project.javaexec and JavaExec

Project.javaexec and JavaExec will now run an executable jar when the property of JavaExec.main  has not been set and the classpath changes to a single file.

In this scenario, Gradle will take the single jar in the classpath as an executable jar and will run it with  java-jar. If you want the proper execution, you need to set the main.class attribute in the executable jar.

9. Fail the Build on Deprecation Warnings

The warning-mode command line option can now use a new fail value that will behave like all. It also fails the build in case any deprecation warning was reported during the execution.

10. Unavailable Files Are Handled Better

Generally, pipes and unreadable files or directories found in inputs and outputs of tasks are managed better than before.

11. Rich Console Output on Linux aarch64 Machines

With Gradle, it is now possible to detect that it is running in an interactive terminal on Linux aarch64 machines. It will generate rich console output on Linux aarch64 machines.

12. Promoted Features

Promoted features were incubating in earlier versions of Gradle but are now supported.

13. Known Issues

Known issues are problems discovered after the release. Those are directly related to changes introduced in Gradle 5.6. There are two known issues:

  • Memory leak using tasks that apply Worker API and process isolation
  • Duplicate entry generated .classpath file

There are enhancements in plugin authors and for tooling providers in Gradle 5.6 update. Java developers can read the entire Gradle 5.6 release notes here. You can provide your feedback for this post in the comments. If you have any question or doubt related to the changes in Gradle 5.6 version, feel free to drop those in the comments section as well.

References

http://docs.gradle.org/5.6-rc-1/release-notes.html

https://docs.gradle.org/5.6.2/release-notes.html

Further Reading

[DZone Refcard] Groovy

Groovy: A Retrospective

Topics:
java ,groovy ,compilation ,groovy 5.6 ,memory leak ,data leak ,faster ,performance ,test ,jvm

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}