# Gradle toolchains are rarely a good idea

DevFeed: [Gradle toolchains are rarely a good idea](<https://devfeed.tech/articles/gradle-toolchains-are-rarely-a-good-idea-20938.md>)

Original publisher: [Read original article](<https://jakewharton.com/gradle-toolchains-are-rarely-a-good-idea/>)

Published: 2024-03-21T00:00:00Z

Content type: opinion

Language: en

Sources: [Jake Wharton](<https://devfeed.tech/sources/jake-wharton.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [toolchains](<https://devfeed.tech/topics/toolchains.md>), [Java](<https://devfeed.tech/topics/java.md>), [Containers](<https://devfeed.tech/topics/containers.md>), [ci](<https://devfeed.tech/topics/ci.md>), [Homebrew](<https://devfeed.tech/topics/homebrew.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>)

Tags: [ci](<https://devfeed.tech/tags/ci.md>), [containers](<https://devfeed.tech/tags/containers.md>), [go](<https://devfeed.tech/tags/go.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [java](<https://devfeed.tech/tags/java.md>), [toolchains](<https://devfeed.tech/tags/toolchains.md>)

## AI overview

The article argues that Gradle Java toolchains are often counterproductive. Using an old JDK can produce outdated, non-searchable Javadoc, ignore container resource limits, and increase the risk of compiler and JVM bugs. The author recommends building with a modern JDK while controlling the target language level through compiler configuration, and keeping installed JDKs up to date.

## Source excerpt

The last post featured some Kotlin code inadvertently targeting a new Java API when the build JDK was bumped to 21. This can be solved with the -Xjdk-release Kotlin compiler flag, or by using Gradle toolchains to build with an old JDK. If you read the Gradle docs... Using Java toolchains is a preferred way to target a language version ...or the Android docs... We recommend that you always specify the Java toolchain ...you wouldn't be blamed for thinking Java toolchains are the way to go! However, Java toolchains are rarely a good idea. Let's look at why. Bad docs Last week I released a new version of Retrofit which uses a Java toolchain to target Java 8. Its use of toolchains was contributed a while ago, and I simply forgot to remove it. As a consequence, its Javadoc was built using JDK 8 and is thus not searchable. Searchable Javadoc came in JEP 225 with JDK 9. The next release of Retrofit will be made without a toolchain and with the latest JDK. Its docs will have all the Javadoc advancements from the last 10 years including search and better modern HTML/CSS. Resource ignorance Old JVMs were somewhat notorious for being ignorant to resource limitations imposed by the system. The rise of containers, especially on CI systems, means your process resource limits are different from those of the host OS. JDK 10 kicked things into high gear with cgroups support and JDK 15 extended that to cgroups2. Both of those changes were backported to the 8 and 11 branches, but since Gradle toolchains will use an already-installed JDK if available you have to have kept your JDK 8 and/or JDK 11 up-to-date. Have you? Not to stray too far off-topic, but if you installed it with SDKMAN! or similar JDK management tools there's a good chance it's wildly out of date. I keep all my JDKs up-to-date by installing them through a Homebrew tap which itself updates automatically using the Azul Zulu API. As long as I do a brew upgrade every so often, each major JDK release that I have installed will be upd