The first milestone release toward Gradle 3.0 has just been published, and among many smaller improvements, it contains two major features we’d like to get your feedback on.
The first feature is support for writing Gradle build scripts in Kotlin, and you can read all about it in last month’s Kotlin meets Gradle blog post. While still in the early stages of development, this functionality is now available out of the box with Gradle 3.0 M1, and we’d love to hear what you think. See the Gradle Script Kotlin 1.0 M1 release notes for complete details and getting started instructions.
The second feature is that the Gradle Daemon is now enabled by default. This is a big deal, and I want to focus on it for the rest of this post.
What is the Gradle Daemon?
The Gradle Daemon is a long-running background process — a “warm JVM” — that Gradle can connect to from the command line or from within your IDE. The daemon keeps track of all kinds of information about your project’s build and makes that information available instantaneously. The result is that Gradle doesn’t have to recalculate all that information each time you run
gradle build or
gradle test or any other task. And the benefit to you, of course, is that your build times get a whole lot faster.
The daemon has been available since way back in Gradle 0.9, but until now it’s been an opt-in feature, meaning that users have had to provide the
--daemon option at the command line or otherwise set Gradle’s
org.gradle.daemon property to
true in order to take advantage of it. This approach worked perfectly well, but only if you knew about it. And while many Gradle users do know about the daemon, and make use of it every day, we know from interacting with our community that the majority of Gradle users do not yet take advantage of the daemon.
So if you haven’t been familiar with the daemon until now, or if you’ve struggled to make your colleagues aware of this feature, don’t worry — you’re not alone. It’s for these reasons that we’ve made enabling the daemon by default a key part of Gradle 3.0.
Unleashing the Daemon
Over the years, the daemon has become an advanced and highly capable piece of software. But enabling it by default isn’t as simple as just “flipping a switch”. This change is profound — it means that from 3.0 forward, every Gradle user will interact with the daemon on every build unless they explicitly opt out. That’s a whole lotta builds, and with numbers like that, it means that even the tiniest bugs and most obscure corner cases are likely to surface where they haven’t before. This is why we’ve invested significant engineering effort over the last several months to ensure the daemon is up to this new challenge — and it’s why we’re so eager to get your feedback on this first milestone.
Trying out 3.0 M1 and its auto-enabled daemon is easy. Just update your Gradle wrapper using the following command and then run your builds as you normally would:
gradle wrapper --gradle-version 3.0-milestone-1
And of course, if you have any problems, comments or questions, let us know!
The Daemon in Action
The short asciicast below demonstrates upgrading a project’s build from Gradle 2.13 to 3.0 M1 and shows off the resulting performance gains side-by-side in a before-and-after comparison. As you’ll see, the results are pretty dramatic—the project’s
clean build time is cut by more than half:
There’s More Performance Goodness to Come
If you run Gradle builds at all, there’s a good chance you run them dozens of times every day. This means that every second counts, and that’s why enabling the daemon by default is just one of a number of performance-related efforts we’ve been up to. Indeed, consistent with the other meaning of the word daemon, you might say we’ve been hell-bent on making Gradle the fastest and most capable build system in the world. There’s plenty more work to do to achieve that goal, and your feedback will help every step of the way. To that end, we hope you’ll check out the 3.0 M1 release notes, try it out for yourself, and let us know how it goes. Thanks!