Gradle 3.0 M2: Initial Java 9 Support and Performance Improvements
The second milestone of Gradle 3.0 has just been released, and this version comes with initial support for Java 9!
It means that Gradle now runs properly when executed on the latest Java 9 EAP builds, but also that you can build and run tests using early versions of JDK 9. It is however important to understand that while you can compile and test applications with JDK 9, we do not support modules, nor any JDK 9 specific compile options (like -release or -modulepath) yet. However we would gladly appreciate any feedback with your own projects.
More performance improvements
This milestone is also a good moment to check out our latest and greatest performance improvements. It’s always better to perform measurements on real life builds, so the example below uses the Golo programming language as a guinea pig, and compares the execution time of a clean build of this project. The left pane is using Gradle 2.12 while the right pane is using Gradle 3.0 M2 with a “hot” daemon:
As you can see having the daemon by default makes your builds significantly snappier, although the performance improvements we’ve made since Gradle 2.12 go beyond just using the daemon. For those of you who were already enabling it in previous versions of Gradle, you should also see better performance, as this next screencast shows:
Since Gradle 2.12, we’ve made significant progress that can be summarized in a few lines:
- configuration time is now faster, meaning that the time it will take from the moment you invoke a Gradle task and the moment the task is actually executed is much shorter. especially apparent on large multi-module builds.
- execution with the daemon has been optimized, meaning that in Gradle 3.0 having it enabled by default, you will immediately benefit from faster builds
- build script caching has been reworked so that subsequent builds are not only faster to configure, but also that builds running concurrently will no longer hang. This is particularly important for non-isolated builds running on a CI server
As an illustration of those improvements, we tried to execute gradle help with the daemon on on the Apereo CAS project, which consists of a large multiproject builds, which typically greatly benefits from those improvements. Again, the left side is using Gradle 2.12, while the right side uses 3.0 M2:
Last but not least, we also took a look at the rare cases where Gradle was still slower than Maven and fixed those. The following screencast is an illustration of what you can expect from Gradle 3.0 compared to Maven. This project features a build with 25 subprojects, each having around 200 files and unit tests. Then we ask both Gradle and Maven to assemble it without running tests.
Ultimately, one of the biggest differences between Gradle and Maven is that Gradle is aware of all input/outputs of tasks. As such, it’s smart enough to know about when it has to do something or not. So when we execute the same tasks again, it will not re-execute them if nothing changed:
Check out our performance guide
Having high performance builds is key to build happiness! As such, we focus heavily on performance improvements to Gradle itself. However, there are also many things that users can do to make their builds faster. To that end, we’re currently writing a performance guide, and we invite everyone to take a look at it. It’s in draft form at the moment, but already contains many valuable hints about how to make your Gradle builds even snappier. Please do give it a read, and we’d love to hear your feedback via the guide’s GitHub Issues.