Gradle 3.4 is now available
We’re excited to bring you 3 incredible performance features in this release.
First up: Compile Avoidance. We’ve introduced a new mechanism for up-to-date checking of Java compilation that is sensitive to public API changes only. This means that if you change a comment or even a private API in a downstream project, Java compilation for upstream projects will be UP-TO-DATE.
Next: A stable incremental Java compiler. We’ve smartened the handling of constants, backed it with in-memory caches, and fixed many bugs. It is now production-ready for your build and has been promoted out of @Incubating.
Finally: A brand new Java Library Plugin. Use this when building a component intended to be used as a dependency from another project. It provides a strong separation between public (exported) and private code which not only gives great performance benefits (because consumers’ compile classpaths are smaller), but also an architectural tool for library authors.
Put these together on our perf-enterprise-large benchmark Java project, and compilation time after a method body change is reduced from 2.5 minutes to 9 seconds! Let’s put that in perspective:
It is not just large projects that reap the benefits, for example the same use case for Apache Polygene was reduced from 14 seconds to 7 seconds. Huge kudos to our performance team for delivering such massive performance improvements with this release.
Now, with your help and guidance we’ve been able to made a couple of highly-requested code-quality plugins improvements:
- The JaCoCo plugin now allows you to enforce code coverage metrics and fail the build if they’re not met.
- The default version of JaCoCo used by the JaCoCo plugin has been raised and the plugin is now Java 9-ready.
- The Checkstyle plugin now allows a maximum number of warnings or errors to be configured.
A special thank you to those who voted and contributed to these issues.
The community’s voice clearly indicated the need for verifying JaCoCo code coverage metrics. The JaCoCo plugin in Gradle 3.4 verifies code coverage metrics and will fail the build if code coverage falls below a configurable threshold. The plugin is also fully prepared to run on Java 9.
Last but not least, we’ve made it more convenient to let Gradle know when you want a build scan — just use --scan (or --no-scan if not). No need for the “magic” system property -Dscan.
We hope you’re able to build happiness with Gradle 3.4, and we look forward to your feedback via Twitter or on GitHub and sharing other amazing features in 2017. Happy new year from the Gradle team!
Check the full 3.4 release notes for more information. If no regressions are reported, a final release will typically follow in the next week.
Upgrade Instructions
Switch your build to use Gradle 3.4 quickly by updating your wrapper properties:
./gradlew wrapper --gradle-version=3.4
Standalone downloads are available at https://gradle.org/releases.
Reporting Problems
If you find a problem with Gradle 3.4, 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.