Use 'Toolchains for JVM projects' of Gradle 6.7+
See original GitHub issueGradle 6.7 introduced ‘Toolchains for JVM projects’.
Reference: https://docs.gradle.org/6.8.2/userguide/toolchains.html
So my suggestion is changing sourceCompatibility
to:
java {
toolchain {
languageVersion = JavaLanguageVersion.of(generation)
}
}
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:5 (3 by maintainers)
Top Results From Across the Web
Toolchains for JVM projects - Gradle User Manual
Setup all compile, test and javadoc tasks to use the defined toolchain which may be different than the one Gradle itself uses. Gradle...
Read more >Running Multiple JDK Versions with the Gradle Toolchains ...
The Toolchains for JVM projects documentation displays more information, such as specifying a vendor's JDK. This is super helpful, and unlike ...
Read more >Gradle JVM Toolchain Support in the Kotlin Plugin
What is the Gradle JVM toolchain feature and how to use it? Issues with building Gradle JVM projects; Kotlin repository suffered as well ......
Read more >Can we force the use of a JDK as Gradle Java toolchain?
(from docs.gradle.org: Toolchains for JVM projects). Thus, the JDK is chosen if we have both, JRE and JDK, installed. Problem: Imagine that the ......
Read more >配置 Gradle 项目 - Kotlin 官方文档 中文版
Gradle 6.7 introduced Java toolchains support. Using this feature, you can: ... With toolchains support, Gradle can autodetect local JDKs and install missing...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Thanks for the suggestion, but I don’t think we should do this. Using Gradle’s Toolchain support may result in it attempting to download a JDK to meet the project’s needs. That’s something that may not always be desirable and in some organisations it wouldn’t be permitted. I think it’s better if we leave it as an opt-in.
Let’s see what the rest of the team thinks.
As Andy mentioned, we really need to add what is strictly necessary out-of-the-box and let users complete their build with additional options if necessary. Thanks for the suggestion, in any case.