# How Gradle Is Javamaxxing

DevFeed: [How Gradle Is Javamaxxing](<https://devfeed.tech/articles/how-gradle-is-javamaxxing-24628.md>)

Original publisher: [Read original article](<https://blog.gradle.org/gradle-is-javamaxxing>)

Author: Laura Kassovic

Published: 2026-05-28T04:00:00Z

Content type: article

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Java](<https://devfeed.tech/topics/java.md>), [toolchains](<https://devfeed.tech/topics/toolchains.md>), [toolchain](<https://devfeed.tech/topics/toolchain.md>)

Tags: [bytecode](<https://devfeed.tech/tags/bytecode.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [garbage-collectors](<https://devfeed.tech/tags/garbage-collectors.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [java](<https://devfeed.tech/tags/java.md>), [java-8](<https://devfeed.tech/tags/java-8.md>), [jdk](<https://devfeed.tech/tags/jdk.md>), [jvm](<https://devfeed.tech/tags/jvm.md>), [openjdk](<https://devfeed.tech/tags/openjdk.md>), [optimization](<https://devfeed.tech/tags/optimization.md>), [performance-optimization](<https://devfeed.tech/tags/performance-optimization.md>), [release](<https://devfeed.tech/tags/release.md>)

## AI overview

Gradle aggressively adopts new JDK releases because newer JVMs can improve build speed, memory use, startup behavior, and maintainability. JVM toolchains allow Gradle to run on JDK 26 while compiling and testing projects for older Java versions, including producing Java 8-compatible bytecode.

## Source excerpt

Some people optimize one part of their lives to the absolute limit, then past it. They call it "-maxxing." 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. Because newer JDKs make Gradle faster, leaner, and easier to maintain. Every OpenJDK release ships improvements to the JVM; garbage collectors, compiler infrastructure, startup behavior, memory layout, and runtime APIs. 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. 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. The full mapping is in the Compatibility Matrix. We then bump the minimum JVM required to execute Gradle as users move. Gradle 9.0.0, released on July 31, 2025, raised the minimum JVM required to run the Gradle daemon to Java 17. 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 10.0.0 will likely