https://gradle.com/ logo
Join Slack
Powered by
Am I misunderstanding how the java toolchain featu...
# community-support
d
Am I misunderstanding how the java toolchain feature works? I expected it to install the configured JDK, but for some reason ./gradlew build uses java 21 even if my build.gradle.kts says 17. There's also no auto-selection working in IDEA, even if there are closed issues that says it should auto-select.
v
How does it "say 17"?
d
Turns out this was a mix of issues, but the auto-selection issue still remains. The language version is correctly set in IDEA, but the project sdk is not changed, so may lead to having language version = 21, but selected jdk java 17. So perhaps this is only an IDEA issue.
👌 1
g
As far as I know, the "project SDK" in IDEA is what Gradle itself will run on, like your 
JAVA_HOME
when you run Gradle from a shell without the IDE. The build will still honor the toolchain choice when compiling Java (or Kotlin) sources, forking another java process with the toolchain JDK, independently from your "project SDK" or 
JAVA_HOME
(the Java and Kotlin plugins do that).
For example, if your `JAVA_HOME`/"project SDK" is set to 
/usr/lib/jvm/zulu17
, JDK 17 must be pre-installed on that path. Toolchains won't install it. Then, independently, if you set toolchain in your build logic to 21, the build (which is running on 17) will install 21 if necessary and use it to compile your Java/Kotlin sources in a separate JDK 21 process. Toolchains are also used to run your Java/Kotlin program by default.
v
As far as I know, the "project SDK" in IDEA is what Gradle itself will run on,
That depends on what settings you did. By default it uses 
JAVA_HOME
as well to be consistent with the commandline execution. And even if compilation is delegated to Gradle, the project sdk is very relevant for example for IntelliSense and language level.
👍🏻 1
d
I wonder if that applies to the flyway plugin as well. Just experimented a bit with this. With languageversion set to 21, and all classes actually compiling to 21 now, the CI with OS JVM 17 can no longer run kotlin migrations via the flyway gradle plugin. In the end it didn't matter as I deploy migrations with the flyway docker image as an ecs task, and that docker image is only built with 17 for now so I can ignore that CI issue a while longer.
v
Tasks / Plugins have to actively support JVM toolchains currently. So if that plugin is not considering toolchains you should post a feature request. But at least you would be able to configure the executable with the one coming from 
javaToolchains.launcherFor...
d
I filed a feature request for configuration cache support 2-3 years ago, and that got insta-closed and remained so dispite other people poking them so I fear that will be in vain. But I'll give it a try. Didn't know that plugins needed specific support, thanks for informing me.
v
Well, as I said, as long as you can configure the executable from outside, you can easily work-around it
Hm, which issue are you referring to? If I search for "toolchain" I do not find any
But well, they do not even use task-configuration avoidance, so I'd say that plugin is not really maintained too well
Oh, I see, the plugin is not at all calling an external process, so of course no toolchains support. It calls flyway in-process in the Gradle daemon. Then of course you cannot configure it from outside and supporting toolchains would probably mean quite some refactoring.
d
Ooh.. didn't think of that. Anyways, it's enough to move over to running on 21. No need to target atm.
3 Views
Open in Slack
PreviousNext
Powered by