Gradle's Evolution - A Conversation with Adam Murdoch

June 12, 2024

Laura Kassovic

General

We had a conversation with Adam Murdoch, the CTO of Gradle, about his journey from the very origins of Gradle. Adam offers insights into the latest features and discusses the future of build tools.

The Genesis of Gradle

Adam began his journey with Gradle around 2008 while seeking a robust alternative to the Ant-based build systems that he used at the time. He recalls, “I was looking for a replacement for our Ant-based build system, came across this new tool called Gradle, started using it, [and] started sending in patches for improvements.”

Hans Dockter, the founder of Gradle, recognized Adam’s contributions and invited him to join as a maintainer. This collaboration marked the beginning of a transformative journey in build automation. “Here we are 15 years later,” Adam remarks, reflecting on the vast changes since those early days.

Recognizing a growing ecosystem

Reflecting on the evolution of build tools over the years, Adam notes the dramatic expansion of the ecosystem. “When we started Gradle, there were no microservices […] building your software meant compiling some classes, making adjustments, and then you were done.”

Today, the landscape is vastly different. Build tools now need to handle various tasks from deployment to production, which were not considered when Gradle first began. The introduction of languages like Kotlin and platforms like Android has further expanded Gradle’s role in the developer community.

• 2012: Gradle Build Tool 1.0 introduces a faster, more accurate dependency resolution engine and expands plugin support.
• 2014: Gradle Build Tool 2.0 improves performance and memory efficiency, introduces new dependency management features, and enhances incremental build support.
• 2016: Gradle Build Tool 3.0 enables the Gradle Daemon by default and enhances IDE support with auto-completion and navigation with Kotlin DSL.
• 2016: Gradle, Inc. releases Gradle Enterprise as a commercial product to build software better and faster with Build Scan® and Build Cache.
• 2017: Gradle Build Tool 4.0 makes the build cache production-ready for Java and Groovy compilation, adds rich console output, and improves incremental compilation.
• 2018: Gradle Build Tool 5.0 promotes Kotlin DSL for build scripts to production-ready, supports Java 11, adds dependency management version alignment, and improves incremental compilation with annotation processing.

Supporting bigger projects

Adam points out that the scope of build tools has expanded, and the scale of software projects has grown exponentially. “Every team is producing more software, more and more each year,” he says, emphasizing the ongoing challenge of enhancing performance to meet these increasing demands. This scalability is crucial, and Adam mentions that Gradle has been focusing on overcoming historical scaling problems by addressing fundamental limitations in the configuration model.

• 2019: Gradle Build Tool 6.0 introduces enhanced dependency management with a new metadata format and improves developer productivity through updated ecosystem plugins and APIs.
• 2021: Gradle Build Tool 7.0 offers faster incremental builds, enhanced security through dependency integrity verification, and support for Java 16.
• 2023: Gradle Build Tool 8.0 debuts the configuration cache, enhances parallelism for faster builds, and improves Java compilation.
• 2023: Gradle, Inc. rebrands Gradle Enterprise to emphasize its universal approach to build tools. Develocity supports Gradle of course, but it also supports Bazel, SBT, and Maven. It also introduces two major features, Test Distribution and Predictive Test Selection using ML (machine learning).

Focusing on developer productivity

Over the last five years, Gradle Build Tool and Develocity engineers have focused heavily on improving developer productivity by:

• Highlighting the significance of fast feedback cycles and early bug detection.
• Quantifying the costs associated with low-productivity environments.
• Improving development processes by leveraging acceleration technologies like caching.
• Using data to proactively enhance the reliability of the development toolchain.
• Identifying and eliminating frequent errors and noisy signals such as flaky tests.

Whether with Gradle Build Tool or Develocity, getting deep insights from builds is “an important tool for productivity.” Adam says, “It’s very easy to fix [issues] once you know about them.”

What’s next?

Adam’s current focus is on Declarative Gradle and Isolated Projects to improve the usability of Gradle. “Historically, the audience for Gradle has been the build engineer, […] we’re shifting that focus towards software developers.”

Isolated Projects

Adam highlights Isolated Projects as a game-changing feature in Gradle. This development focuses on enhancing performance and significantly reducing the memory footprint during builds, promising substantial benefits for developers managing mono-repos or large projects.

When Isolated Projects are enabled, the configuration models of Gradle projects are “isolated” from each other. This means that build logic, such as build scripts or plugins applied to a project, cannot directly access the mutable state of another project. This isolation allows the configuration and tooling model creation for each project to run safely in parallel, with the results being cached and invalidated independently for each project.

Check out the Isolated Projects Documentation Page for more information.

Declarative Gradle

Adam also mentions a project called Declarative Gradle, which aims to make Gradle more software developer-friendly. The idea is that a software developer should be able to upgrade a dependency, add Kotlin support to their project, or add functional tests without having deep knowledge of Gradle. With Declarative Gradle, developers will also benefit from better tooling, primarily in the IDE, by automating changes to the software definition.

With Declarative Gradle, the build definition is expressed in a high-level, descriptive manner rather than through imperative code and build logic. A software developer interacts with software types, expressed using the declarative DSL, to describe what needs to be built, including languages, target platforms, dependencies, and quality checks of the software, without getting into how that software needs to be built:

androidLibrary {
  namespace = "com.google.samples.apps.nowinandroid.core.common"
  dependencies {
    implementation("org.jetbrains.kotlinx:kotlinx-coroutines:1.7.3")
    implementation("app.cash.turbine:turbine:1.0.0")
  }
  buildTypes {
    debug {}
    release {}
  }
}

Programming constructs like control flows are not possible using a declarative DSL. This clearly separates software definition from build logic and allows developers to focus on describing their software in familiar terms while build engineers handle the underlying implementation details in plugins. This approach ensures a cleaner, more intuitive, and maintainable build process.

Learn more about Declarative Gradle:

Declarative Gradle is an experimental project under active development. Currently, no compatibility is guaranteed, and it is not ready for real-world use. There is no commitment to the DSL syntax or available features. We expect to release the First Early Access Preview (EAP) in the middle of 2024 to gather feedback on the direction of the project.

• Head to the Declarative Gradle site to explore prototypes and early getting started guides, including the Now in Android project.
• Watch the Developer-first Gradle builds presentation by Sterling Greene and Paul Merlin at KotlinConf on May 24, 2024.
• Read the initial Declarative Gradle announcement and manifesto.

As for Adam, he says, “It is critical for the success of Isolated Projects and Declarative Gradle that we get feedback from people.” We appreciate any feedback provided as GitHub issues or via the #releases-discussion and #declarative-gradle channels on the Gradle Community Slack.

Discuss