https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# kotlin-dsl
s
This message was deleted.
m
Reading from this, I would say ā€¢ 
jvmToolchain
downloads a JDK 17 if none is installed on your machine ā€¢ 
jvmTarget
will only set the target so if you only have JDK 11 locally, it will most likely fail
I'd go with 
jvmToolchain
personally, it makes it easier to onboard new contributors
p
Thanks šŸ™‚
j
Copy code
kotlinOptions.jvmTarget
That is going to do nothing in 1.8.0 if I remember correctly. But you don't need to have the specific version installed. For example if you have Java 18 and you don't set a 
jvmTarget
, the artifacts will be compatible with Java 18+. If you set 11, even compiling with Java 18, it produces artifacts compatible with Java 11. But it is better to move to 
jvmToolchain
p
Nice, I'm in 1.8.0, so it is now unnecessary to set 
jvmTarget
if I understand correctly. And prior to this it was somewhat useful
e
IIRC you may want the project to be compiled using Java 17, and so you'd set the 
jvmToolchain
accordingly, but you want your code to compile to Java 11 bytecode, and so you'd set 
jvmTarget
to 11.
j
jvmTarget was not working for that in 1.7+ and you have to setup it in the java extension too. I think with toolchain is enough. cc @Tapchicoma
languageVersion
in the toolchain
t
before Kotlin 1.8.0 difference is that Kotlin extension also configures 
jvmTarget
. With Kotlin 1.8.0 there is no difference - both approaches should do the same and also configure 
jvmTarget
wanted to add some additional info which I missed initially - 
kotlin.jvmToolchain
also configures 
-jdk-home
Kotlin compiler argument. This arguments configures which JDK classes will be used in the compilation classpath. My message above was more about 
java.toolchain { ... }
vs 
kotlin.jvmToolchain { .. }
DSL.
šŸ‘ 2
j
to reuse Gradle daemons it is recommended to set the same JDK for home and for IntelliJ. Is there a way to indicate IntelliJ to pick the JDK from this Gradle configuration?
m
The toolchain JDK will always be the same. That happens after the Gradle daemon is started
thank you 1
The JDK used by the daemon is the one from your path or JAVA_HOME and IntelliJ creates a small shell at startup to find out which one it is
šŸ‘ 1
j
so even running Gradle from IntelliJ configuration? That is great, so with Gradle with toolchain, the project structure jdk is irrelevant then
m
Just make sure you use 
JAVA_HOME
in your IntelliJ settings
šŸ‘Œ 1
(Also build and run tests with Gradle)
the project structure jdk is irrelevant then
I think it might still be used for autocomplete in some files, not sure which ones
I've had issues with `build.gradle.kts`files in the past where changing project structure jdk "fixed" things
But for running Gradle tasks and sync from IntelliJ, 
JAVA_HOME
is working quite well for me
t
the project structure jdk is irrelevant then
Generally no as build cache for build scripts relies on JDK version. But could be workaround via convention plugins + Gradle 8+ šŸ™‚
šŸ‘€ 2
m
Generally no as build cache for build scripts relies on JDK version
Isn't that JDK taken from JAVA_HOME (and not project structure)?
(since Gradle is building the build cache, etc... As soon as the daemon is kicked off using JAVA_HOME then everything should be using the JAVA_HOME JDK?)
t
yeah, I mean toolchain JDK does not affect build scripts compilation JDK. So you will see some build degradation on using different JDKs to run Gradle build. But it is a minor thing, imho.
m
Ah right!
There's an issue to make the Gradle wrapper install its own JDK (some kind of higher level toolchain)
11 Views
Open in Slack
PreviousNext
Powered by