How Gradle Is Javamaxxing

How Gradle Is Javamaxxing

Calendar

May 28, 2026

Laura Kassovic

General

Why the Gradle Build Tool aggressively chases the newest JDK and how toolchains keep your build perfectly safe while we do.

Table of Contents

TL;DR<br>NOT TL;DR<br>What Is the Current State of Gradle and Java?<br>Why Bother? Because Newer JDKs Make Gradle Faster1. Features You Can Explicitly Enable<br>2. Features Gradle Can Use Automatically<br>3. Improvements the JVM Gives Everyone Automatically

How Does Gradle Decide When to Raise the Floor?“But My Project Still Supports Java 8”<br>What About --release?

Summary

Introduction

Some people optimize one part of their lives to the absolute limit, then past it.<br>They call it “-maxxing.”<br>Houseplantmaxxing. Sleepmaxxing. Tokenmaxxing.

The Gradle Build Tool is Javamaxxing .

TL;DR #

Breathe easy knowing you can run modern Gradle on JDK 26 while still shipping Java 8-compatible artifacts:

Gradle aggressively adopts new JDKs because newer JVMs make builds faster, leaner, and easier to maintain.

Upgrading the JDK that runs Gradle is often the easiest performance win.

JVM toolchains fully separate the JVM running Gradle, the JVM compiling your code, and the JVM running your tests.

NOT TL;DR #

We aggressively adopt new JDK releases as soon as we responsibly can.

Not because it’s trendy.<br>Because newer JDKs make Gradle faster, leaner, and easier to maintain.<br>Every OpenJDK release ships improvements to the JVM; garbage collectors, compiler infrastructure, startup behavior, memory layout, and runtime APIs.<br>As a high-performance JVM build tool, Gradle benefits directly from all of it.

The question people immediately ask is:

Does this mean my project also has to run on the newest JDK?

No.

That coupling effectively disappeared once Gradle introduced JVM toolchains.<br>With toolchains, the JVM that runs Gradle is completely separate from the JVM that compiles, tests, and executes your code .

You can run Gradle on JDK 26 today and still produce Java 8 bytecode.

What Is the Current State of Gradle and Java? #

We add daemon support for every new JDK as soon as the ecosystem permits: Java 24 in Gradle 8.14.0, Java 25 in 9.1.0 (released two days after JDK 25 GA), Java 26 in 9.4.0.<br>The full mapping is in the Compatibility Matrix.

We then bump the minimum JVM required to execute Gradle as users move.<br>Gradle 9.0.0, released on July 31, 2025, raised the minimum JVM required to run the Gradle daemon to Java 17.<br>That was the first daemon JVM floor increase since Gradle 5.0 made Java 8 the minimum back in 2018.

The next major transition is already underway:

Gradle 9.6.0 deprecates daemon JVMs below Java 21.

Gradle 10.0.0 will require Java 21 to run the daemon.

The timing matches Oracle’s Java SE Support Roadmap, which places the end of Premier Support for JDK 17 in September 2026.<br>By the time Gradle 10 arrives, Java 17 will already be exiting its primary support window.

That’s Javamaxxing.

Why Bother? Because Newer JDKs Make Gradle Faster #

The cheapest, least glamorous, and often most effective Gradle performance optimization is simply upgrading the JDK running Gradle.

Before rewriting custom tasks.<br>Before untangling dependency graphs.<br>Before buying larger CI machines.<br>Just run Gradle on a newer JVM.

You inherit years of JVM engineering work for free.<br>Those improvements generally fall into three categories.

1. Features You Can Explicitly Enable #

Some performance features require opt-in.

A good example is Compact Object Headers (JEP 519).

The feature reduces ordinary object headers from 12 bytes to 8 bytes on 64-bit platforms.<br>According to the JEP benchmarks, this reduced heap usage by roughly 22% and CPU time by about 8% in SPECjbb2015 workloads.

That matters for Gradle.<br>A large Gradle build may keep millions of objects alive simultaneously:

tasks

providers

file snapshots

dependency graph structures

configuration model objects

incremental build state

Saving four bytes per object adds up quickly.

You can experiment with the feature today:

org.gradle.jvmargs=-Xmx2g -XX:MaxMetaspaceSize=512m -XX:+UseCompactObjectHeaders

NOTE: Setting org.gradle.jvmargs replaces Gradle’s defaults rather than appending to them, so preserve any heap or metaspace settings you still want.

2. Features Gradle Can Use Automatically #

Gradle also takes advantage of newer JDK APIs internally.

Gradle ships JDK-version-specific implementations that activate dynamically depending on the JVM the daemon runs on.<br>That lets Gradle use newer platform APIs without requiring all users to upgrade immediately.

Today, this mechanism is still relatively conservative, but it opens the door to deeper integrations over time.

One especially promising example is the Class-File API (JEP 484), finalized in JDK 24.

The API provides a standard JDK-native mechanism for reading and writing Java class files.<br>Historically, most JVM tools depended on ASM for this.

Using a JDK-native API reduces maintenance...