What's new in Gradle 9.0

Gradle 9.0 is a new major release which incorporates many features since the version 8.0. It makes Gradle configuration cache the preferred execution mode, provides more clean and actionable error reporting, and also updates Gradle to Kotlin 2 and Groovy 4.

Key Updates in Gradle 9

Below, you can read a summary of the key updates between Gradle 8.0 and 9.0.0.

NOTE: If you are reading this before the public Gradle 9 release, we invite you to try out the recent release candidates and report any discovered compatibility issues! Make sure to follow the Upgrade Guidelines.

As you can see, we are switching to the 3-digit version format. Starting with 9.0.0, Gradle releases will follow the Semantic Versioning (SemVer) specification for all stable features;
incubating features and internal APIs might have a different lifecycle.

Configuration Cache

The Configuration Cache is one of Gradle’s most popular recent features. Whether you’re building Java, Kotlin, Android, or native projects, it can significantly reduce configuration time, especially in large codebases. Over the past few years, we’ve delivered numerous improvements to make the Configuration Cache more reliable, faster and to improve the adopter and developer experience.

As of Gradle 9.0.0, Configuration Cache becomes a preferred mode and we highly advise that Gradle users start adopting Configuration Cache in their builds. Plugin authors should also aim for Configuration Compatibility in their plugins. Check out the documentation pages for the Adoption Guide, which can help you to get started, troubleshoot, and fix the most common compatibility issues (if any). Also see the recording of the Configuration Cache Webinar for some tips on adoption steps and additional tools.

Configuration Cache as the Preferred execution mode

To facilitate further adoption and compatibility in community-maintained plugins, we now recommend enabling Configuration Cache in most scenarios. While the Configuration Cache will not be enabled by default for your builds in this release, there are notable changes:

• Gradle now recommends enabling Configuration Cache in the CLI output, when it detects that no incompatible features were used.
• For newly generated projects, when using gradle init, the Configuration Cache is now enabled by default.
• Developer tooling and the Configuration Cache documentation have been considerably improved to facilitate adoption and troubleshooting.
• Core Gradle plugins and build tasks can now gracefully downgrade the build mode when they are not compatible with the Configuration Cache. You will now be able to permanently enable the Configuration Cache even when using not fully compatible Gradle plugins without experiencing build failures.
• Gradle 9 removed many previously deprecated APIs that are incompatible with Configuration Cache, in favor of safe and idiomatic alternatives that are compatible with Configuration Cache. This cleanup and deprecations will continue in the next releases.

In the upcoming minor Gradle 9.x.y releases, we will focus on the plugin ecosystem compatibility, developer tooling, increased cache hit rates, and better performance, with a goal of enabling Configuration Cache by default in Gradle 10.

Read More for the 9.0.0 release: 9.0.0 Changelog, Upgrade Guidelines

Configuration Cache encryption

Starting from 8.1, Gradle now encrypts the configuration cache to mitigate the risk of accidental exposure of sensitive data. Gradle will transparently generate a machine-specific secret key as required, cache it under the Gradle user home directory, and use it to encrypt the data in the project-specific caches.

Full support for Dependency Verification

Gradle provides support for dependency verification via additional metadata files. Gradle supports both checksum and signature verification as an opt-in feature. From Gradle 8.1, dependency verification is fully supported in the Configuration Cache execution mode. Changes to associated files (keyring files or verification-metadata.xml) are correctly detected and invalidate the configuration cache if necessary.

Deduplicating strings

In Gradle 8.10, we introduced a significant reduction in the cache file size, thanks to string deduplication and accelerated cache loading times at the same time. For example, the Android X team reported a 3.75x size reduction.

Parallel Load and Store in Configuration Cache

In Gradle 8.11, we significantly improved Configuration Cache performance by loading and storing cache entries in parallel (see the release notes). Our benchmarks show a significant performance improvement and parallel configuration provides further improvement in many scenarios. One adopter reported a 50% reduction in configuration time for a build with ~600 projects, cutting it from 2m4s to 55s while reducing cache size from 700 MB to 400 MB.

See More: Gradle 8.11 Release Notes, Documentation Page, Blogpost by Inaki Villar

More performance improvements

Configuration Cache provides a great speed boost, but there are more important changes that improve the overall Gradle performance, especially when building projects and doing the IDE sync.

Kotlin build script compilation avoidance

Kotlin DSL enables much better IDE assistance for build authors, but the longer compilation time of Kotlin compared to Groovy can be an issue for large projects. Together with the JetBrains and Google teams, we keep working on the performance of builds using Kotlin DSL. By leveraging the Kotlin 2 features (see below), Gradle 9.0.0 speeds up feedback loops when editing build logic by avoiding unnecessary recompilation of Kotlin DSL (.kts) build scripts.

In the example below, we observed a 2.5x speedup for listing :help after a build modification.

See the overview video below as part of the Kotlin 2 section.

Memory usage reduction

Gradle 8.1 and 8.3 introduced significant memory use optimization for dependency resolution. This benefits most builds, but the gains are more substantial for the IDE sync process, in particular for complex projects with many dependency resolution operations.

Improved IDE performance by Tooling API optimization

Starting with Gradle 8.8, the Tooling API’s execution of extensive task graphs has been optimized, resulting in performance improvements of up to 12% in large, up-to-date builds with over 15,000 tasks in their task graph. Updating your Gradle version will immediately benefit Android Studio, IntelliJ IDEA, Eclipse, and other Tooling API clients.

See the changelog entry for more details.

Kotlin and Kotlin DSL

Kotlin DSL for Gradle uses the Kotlin language to enable full IDE assistance for build authoring in IntelliJ IDEA and Android Studio. This includes auto-completion, smart content assist, quick access to documentation, navigation to source, and context-aware refactoring. With Kotlin DSL, you can edit your build logic with the same editing experience you are used to when working with your production and test code. Groovy DSL remains fully supported, and there are no plans for deprecation. We keep improving Kotlin DSL integrations and performance, with many changes delivered since 8.0.

Learn More about Kotlin DSL in Gradle.

Kotlin DSL became the default for new builds

In April 2023 (Gradle 8.2), Kotlin DSL became the recommended option for new Gradle projects, and defaults in gradle init and our User Guide reflect this. Kotlin DSL also became the default in new IntellijIDEA and Android Studio projects. We anticipate most of the new projects to use Kotlin DSL going forward.

Update to Kotlin 2

Kotlin 2.0, released on May 21, 2024, marks a major milestone - it brings numerous language enhancements, such as explicit backing fields, smarter type inference, more precise smart casts (even after ||, within lambdas, and across nullable expressions), and deeper integration with tools like Compose Multiplatform. In 2025, the Kotlin 2.1.0 and 2.2.0 versions were released with further improvements.

Gradle 9 embeds the latest stable release of Kotlin 2.2.x runtime and uses Kotlin language version 2.2. This marks a shift from Gradle 8.x, which embedded Kotlin 2.0 starting in 8.11 but continued to use Kotlin language version 1.8 for compatibility. Those using Kotlin DSL for build definitions and developers of Kotlin-based plugins for Gradle now get access to new language features and get a better experience when using IDEs and other developer tools. At the same time, Kotlin 2 introduced a number of syntactical and semantic breaking changes, so upgrading your build and plugins when updating to Gradle 9 might be necessary.

Learn More: Changelog Entry, Upgrade Guide

Kotlin DSL improvements

In Gradle 8.x, we have kept improving Kotlin DSL in order to offer a better developer experience, with many improvements for new and existing features. Key highlights include:

• Simple property assignment in Kotlin DSL scripts with the = operator in 8.6
• Version Catalog API is now available in precompiled scripts in 8.5
• DSL for new features, especially for Variants and Attributes
• A dedicated Kotlin DSL reference created using Dokka, so the layout is familiar to Kotlin developers
• Better integration with Kotlin tools for errors and warning reporting, ability to fail on warning from script compilation, and also enforcing Kotlin metadata checks

Faster first use

Starting from Gradle 8.5, Kotlin extensions for the Gradle API ship as part of the Gradle distribution. Consequently, the first use of a Gradle version for compiling .gradle.kts scripts is much faster, with about 4 seconds saved for the first run on powerful machines. This is especially noticeable on ephemeral CI agents or Gradle plugin cross-version tests.

See the changelog entry for more info.

JSpecify and Kotlin Binary API change

Since Gradle 5.0 we’ve been using annotations from JSR-305 to make the nullness of type usages explicit for the Gradle API. Starting with Gradle 9, the Gradle API is annotated using JSpecify instead. Kotlin 2.2, when combined with JSpecify annotations in the Gradle API, introduces stricter nullability handling and may generate different binary APIs.

This change may impact all plugins and builds implemented in Kotlin, but it also greatly reduces the risk of issues related to nullable APIs. For more details and potential breakages, see the dedicated upgrade guide section.

Java versions and Toolchains

As Java keeps evolving, Gradle keeps evolving along with it and adding support for new versions, and new features that improve the developer experience.

Java 17 is the minimum version to run Gradle

Starting from this release, Gradle requires Java 17 as a minimum version to run Gradle itself. You will need to upgrade your runtime to this version. See the Gradle Compatibility Matrix for more information about the supported versions and configurations.

If you are building Java projects with older Java versions, you can still specify them using the toolchains or other means of separating Gradle runtime and build versions.

Learn More: Changelog Entry, Upgrade Guide

New versions of Java are supported for running and building Gradle projects

We incrementally add support for new versions of Java, for both building the projects with the specified Toolchain and running Gradle itself. Gradle 8.0 supported versions up to Java 19, and the new Gradle 9.0.0 release supports versions up to Java 24 for both use cases.

See the Compatibility Matrix for the actual state of Java support and recommendations.

Support for JAVA_HOME as a Toolchain location

Starting from Gradle 9.0.0, you can rely on the value of the JAVA_HOME environment variable for toolchain autodetection. Gradle now discovers and uses the Java version provided through the standard environment variable.

Support for GraalVM in the toolchains

Starting from 8.18, Gradle’s toolchain support allows provisioning and selection of specific JDK versions for building projects—compiling code, running tests, and even running Gradle itself. If the nativeImageCapable flag is set, Gradle will select only JDKs that support Native Image when resolving a toolchain.

Learn More: Documentation Entry

Gradle Daemon Improvements

Toolchain for the Gradle Daemon

Since Gradle 8.8, users can specify a different JVM for running the Gradle Daemon than the one used to run the Gradle CLI by configuring the Daemon JVM criteria. Gradle first attempts to locate a compatible Java toolchain from installed versions—this process is known as Daemon JVM auto-detection. With the introduction of Daemon JVM auto-provisioning in 8.13, Gradle can also download a matching Java toolchain when none is found locally.

Starting from 8.10, Daemon JVM criteria support specifying the JVM vendor. When considering available JVM toolchains, Gradle will only choose a toolchain compatible with both the specified JVM vendor and version. See the changelog entry for more info.

For more information, see Daemon JVM criteria in the User Guide.

Faster builds by keeping the compiler daemon alive between the builds

Gradle 8.3 made Java compilation faster on Linux and macOS, by keeping compiler daemons alive between builds. Gradle’s internal performance tests show up to a 30% build time improvement for builds that are dominated by compiling Java sources. 8.4 added the same compatibility for Windows builds.

Filesystem watching on Alpine Linux

File-system watching is now supported on Alpine Linux, a popular choice for container-based images and the default distribution for Docker.

Update from Groovy 3 to Groovy 4

Gradle embeds the latest stable release of Groovy 4.0, a major upgrade from the Groovy 3.0 version used in Gradle 7 and 8. Gradle 4 introduces a range of new features and improvements to the Groovy language. For a comprehensive overview of what’s new, see the Groovy 4.0 release notes for full details.

In Gradle ecosystem, Groovy is used for several things: Groovy DSL build scripts (`.gradle` files); build logic in common and convention plugins that can be partially implemented with Groovy, Ant integration.

With all major upgrades, some behavior has changed, but we expect this to mostly impact plugins written in Groovy and not build scripts using the Groovy DSL. As a result, it may impact builds leveraging such plugins (for example, issue #1469 in the Shadow Plugin). If you’re upgrading to Gradle 9, check out the new versions of the plugins you use for known compatibility fixes.

Learn More: Changelog Entry, Upgrade Guide

Build authoring

At Gradle, we want to provide the best possible user experience, especially to software developers who are less experienced with build authoring. Whether you use Gradle from the CLI, your favorite IDE, or in a CI/CD system, Gradle 9 should improve your experience. It includes providing better DSLs and APIs for those who develop Gradle builds, and also better tools for troubleshooting build and sync failures. Providing clean and actionable error reporting has been one of the major themes for Gradle Engineering teams in the past years, with many features delivered in Gradle 8.x and planned for Gradle 9.

Problems API

One of the key highlights of the 8.x releases is the new Problems API that already provides assistance for many use-cases like deprecations, configuration cache compatibility, compilation warnings, etc. Watch the summary of what we delivered in the recent releases:

Problems HTML Report

Starting from Gradle 8.11, the reported problems are also summarized in a new HTML report in addition to the CLI output and API. This report serves as a central location for users to review problems occurring in a build, whether they originate from internal or external plugins. The report is enabled by default in Gradle, and you can find a link to it in the console output.

Better error reporting

Gradle error reporting has improved considerably between the releases. The changes include, but are not limited to: suppressing duplicate error reporting when multiple failures have the same cause, detailed information for Configuration Cache misses, better reporting for failed plugin application, and JVM matching.

Support for Test Dry Run

When testing your project, it may be useful to check which of the tests that you selected would run without actually executing them, especially when using test filtering. Gradle 8.3 introduced a test dry run mode, which can be enabled by either the --test-dry-run command-line option or via the dryRun property.

This mode is compatible with the JUnit and TestNG frameworks.

Better reporting for skipped tests

Starting from 8.14, when a test is skipped due to an assumption violation, Gradle now includes the reason in both the HTML and JUnit XML reports. This applies to JUnit 4, JUnit Platform, and TestNG. See the Changelog Entry for more info.

Build Init Improvements

Gradle Build Init received a number of improvements to ensure compliance with the new features and best practices.

• Default to generating Kotlin DSL builds in 8.2
• Support for Apache Maven projects conversion to Gradle in 8.2 (see the Migration Guide)
• Generating builds with version catalog in 8.5
• Support for a Java version parameter 8.5
• Support for skipping interactive questions in 8.6
• Enabling Configuration Cache by default in 8.11

More Build Init features are accessible via additional plugins, for example, generating Declarative Gradle builds.

Additional improvements

There are also more changes and quality-of-life improvements. The Gradle changelog has the full list of changes in minor releases. Some of the key highlights are:

• Variant API improvements to simplify fetching dependencies based on the required attributes and capabilities
• TestEventReporting API in 8.13, enabling build authors to report test events from outside the Test task
• Artifact transforms: report task (Gradle 8.13 Release Notes) and detection of ambiguous chains (Gradle 8.12 Release Notes). In addition, artifact transforms are now rendered in Build Scans, improving the understanding of the build.

Strengthening the supply chain security with Gradle

We continue to invest in supply chain security for Gradle projects. In particular, it’s critical for developers to reproduce the builds and troubleshoot their contents. Tracking dependencies and detecting potential vulnerabilities is also a priority for all modern build systems, including Gradle. Between Gradle 8.x and 9.x, we made a number of improvements to support it.

Reproducible archives by default

Gradle now produces reproducible archives by default, ensuring byte-for-byte identical content for JARs and ZIPs and other Java packages. While consistent timestamps, permissions and file order have been available since version 3.4, these options are now configured by default.

This change is a step towards reproducible builds that aims to strengthen trust that a binary was really produced from some specific sources. Additionally, this change will also help tools outside of Gradle that can work better with byte-for-byte equivalence.

It’s important to note that this can be a breaking change for some users. The reproducible archives Gradle 9 produces have reproducible file order, fixed timestamp, and preconfigured permissions. If your build depends on a specific file order, changing timestamps, file system permissions, or file executable bits, you may need to reconfigure your archive task.

Learn More: Changelog, Upgrade Guide

GitHub Actions & Dependency Submission Action

As part of the supply chain security partnership with GitHub, we released the new Dependency Submission Action for Gradle. This action can be configured to automatically submit dependencies to GitHub’s dependency graph and receive Dependabot alerts for potentially vulnerable direct and transitive dependencies. Read more in the announcement blog post and official press release. We also published a short overview video here.

The GitHub team has also continued improving the Dependabot capabilities. In May 2025 GitHub introduced dependency-autosubmission for Gradle dependencies. As of June, Gradle lockfiles are also supported by Dependabot- see Locking Versions for more info.

Gradle Wrapper improvements

The Gradle Wrapper tasks now support symbolic names (8.1) and validate the distribution URL exists (8.2). Starting from Gradle 9, it is also possible to request Gradle versions by using a partial SemVer specification, e.g. by requiring “9” or “9.1” instead of the 3-digit version specification (changelog entry).

Other features

The list above highlights only the key changes in the Gradle 9.0.0 release and the key themes in the recent minor versions. The release also includes many smaller enhancements, bug fixes, and deprecated API removals. Some of the core Gradle plugins, for example, the static analysis and native support ones, have also received major improvements.

These changes might be important to some users. They can be found in the Gradle changelog or in the documentation pages for particular plugins.

Build Scan and Develocity integrations

In Gradle, any user can analyze their builds, troubleshoot performance and dependencies, and get more insights into the build process with the help of the free Build Scan service provided by Gradle, Inc. This service uses the Develocity Gradle Plugin for publishing and keeps improving with the new versions of Develocity and Gradle Build Tool.

There have been many changes delivered in the timeframe between the Gradle 8.0 and 9.0.0 releases. Some of them are specific to Gradle 9, some are available to previous versions too:

• AI-based grouping for build and test failures
• Support for build environment system resource usage reporting, including CPU, RAM, network, and disk I/O
• Insights into artifact transforms
• Providing more metrics and details about Configuration Cache, including reporting on cache miss reasons
• Isolated Projects is now supported for all Build Scan and Develocity features
• Multiple integrations for Develocity-specific features, e.g. better reporting on predictive test selection and test parallelization savings
• Improved developer APIs and DSL syntax for configuring the plugin.
• Better reporting and visualization for key Gradle metrics, CLI outputs, and reports

If you have not tried Build Scan yet, check out the short Gradle Build Scan course at DPE University that provides a guided tour through the main features provided by the tool.

Learn More: Build Scan Documentation, Develocity release notes, Develocity Gradle Plugin release history.

Documentation updates

The Gradle User Guide is one of the most frequently visited Gradle resources, and we continue to invest in it to provide clear, well-structured documentation covering both fundamental and advanced Gradle features. Between Gradle 8.x and 9.x, the User Guide has undergone several major improvements:

• The Gradle User Manual was restructured with dedicated pages for key features and an improved navigation experience. New introductory material, including tutorials, was added.
• The site search engine was replaced with Algolia DocSearch v3 and customized to deliver more relevant and searchable results.
• Code samples and snippets were refreshed to align with current Gradle best practices. Additionally code snippets can be copy pasted and full working projects can be downloaded.
• A new feedback form was introduced to make it easier for users to suggest improvements.
• Gradle Release Notes now include section anchors, making it easier to reference specific changes. An experimental Gradle Cookbook was published—an open-source collection of recipes, guides, and integration examples with other tools and services.
• New Best Practices Guide was published that helps developers adopt recommended patterns and avoid common pitfalls. This guide should especially help address common concerns about Gradle offering multiple ways to do the same thing. This ongoing effort is a collaboration between Gradle, Google, and JetBrains. Look out for new items being introduced in future versions.

All documentation remains open source, and we invite you to contribute! See the Documentation Contributor Guide.

Training materials and courses

In May 2024, Gradle, Inc. launched the new free learning portal, DPE University. It replaced the old courses posted on gradle.org and many older Gradle Guides.

The new training portal includes multiple self-led training courses designed to support developers and build platform engineers across all experience levels, from beginner software developers to experienced build engineers leveraging Gradle or Develocity. Upon completing certain training, you can earn a certificate which can be shared on your LinkedIn profile.

Gradle websites - new look & updates

In May 2025, we refreshed the look and feel of the gradle.org website! In addition to the new look, you’ll find simplified navigation to help direct you to important resources, including documentation, learning materials, and key feature overviews. We also invested in underlying tooling so that the new changes and updates can be delivered quickly.

Some other updates related to Gradle resources:

• Gradle Newsletter and Blog got new looks, support for tables of contents, and chapter anchors, so you can easily search for and share information with your peers. You can also subscribe to updates via RSS!
• We have started a new open-source Gradle Community Site that aggregates resources for contributors, including contributor guides and events like Google Summer of Code
• A new standalone site was launched for the Declarative Gradle project

Excluded / Delayed features

Provider API migration

The Provider API migration is an effort to embrace lazy configuration and to make APIs for Kotlin DSL and Groovy DSL consistent. On March 28, 2025, we decided to exclude the Provider API migration from the Gradle 9.0 scope. Based on early feedback, we confirmed that better IDE support is essential to make this migration successful for users. This IDE support requires both enhancements within Gradle and corresponding adoption of those changes in IntelliJ IDEA and Android Studio.

We remain committed to the Provider API migration and are actively working to complete the remaining unmigrated properties. Our aspirational goal is to include them in Gradle 10, which is targeted for 2026.

Incubation status of Isolated Projects

Isolated Projects is a pre-alpha Gradle feature that builds on the Configuration Cache to further improve performance, particularly during Android Studio and IntelliJ IDEA sync. While some sources announced that Isolated Projects would be incubating in Gradle 9.0, the actual plan is to promote the feature in a later Gradle 9.x release.

Gradle 9.0.0 will not include changes specific to Isolated Projects. Priority has been given to productizing the Configuration Cache, which is a prerequisite for the success of Isolated Projects. Once the work for this major release is complete, development on Isolated Projects will resume.

Upgrading to Gradle 9

As with any other major release, updating to Gradle 9 requires a careful approach as there are multiple potentially breaking changes. These include, but are not limited to, bumping the minimum required Java version, removing deprecated APIs and features, breaking changes in Kotlin and Groovy DSLs due to upgrades to Kotlin 2 and Groovy 4, and changes in the generated binary APIs for Kotlin-based implementations after the adoption of JSpecify annotations. All of that may result not only in incompatibility of your builds, but also of the plugins used in them.

While we anticipate a relatively smooth migration to Gradle 9 by the majority of Gradle users, your mileage may vary depending on the complexity. We urge everyone to carefully review and follow the Upgrade Guidelines and test the new release before a wide rollout in your organization.

NOTE: If you are reading this before the public Gradle 9 release, we invite you to try out the recent release candidates and report any discovered compatibility issues!