This message was deleted.

have always used toolChain for consistency between IDE / CLI / CI builds. IntelliJ will take it from there.

What is this "toolChain" you speak of? 🙂 Is that in gradle?

In gradle (docs). A typical usage would be something like

java {
    toolchain {
        languageVersion.set(JavaLanguageVersion.of(11))
    }
}

One can also set the JVM vendor (Adoptium, etc) to use if so desired. Note the toolchain JVM version is separate from the JVM used to execute Gradle. For all our Gradle builds, the Gradle JVM is 17 with the toolchain set per-project as required.

thanks for the great explanations!

shouldn’t be a problem - it’s still the same JavaCompile task / settings, internally the logic figures out which JVM to execute.

--release

may not be required, as the toolchain explicitly sets the JVM version to use.

normally, setting

sourceCompatibility

and

targetCompatibility

would suppress

--release

flag, but we can't use those anymore w/ toolchain.

they aren’t needed with toolchain - the compatibility stuff is only for when you are using one JVM for multiple things (running Gradle, compiling X, Y, Z, etc) - with toolchain you can separate those concerns.

Why should you use

source- / targetCompatibility

if you are using Java toolchains feature? One practially superseeds the other. You configure the toolchain that you would have set for compatibility.

we need

--add-exports

. This does not work with

--release

and using toolchains causes

--release

to be used.

Toolchains should not use

--release

I think. It is not necessary, as the correct Java version is used to execute the compiler, so

--release

would be superfluous, wouldn't it? Besides why should add-exports not work with release?

we only add the exports when java version >8. I'll check gradle/IJ are all on 17....

are there arguments, such as --release, passed to the JavaCompile task?

just

--add-exports

ok. can’t recall seeing

--release

being part of the arguments, worth figuring out where that is coming from.

ahhh, I think I see it. probably my bad.

It’s perhaps this issue: https://github.com/gradle/gradle/issues/18824

ahhhhh, I think you are right!

there’s a reasonable workaround in there that hopefully with sidestep this.

yup. 💯 perfect!

Hm, strange, it wonder why the release flag is set at all, as the correct jdk is used already. Must have remembered wrongly it seems.

yea, was confused as well. it boils down to this Gradle code:

if (!isSourceOrTargetConfigured) {
                    JavaLanguageVersion languageVersion = toolchain.getLanguageVersion();
                    if (languageVersion.canCompileOrRun(10)) {
                        spec.setRelease(languageVersion.asInt());
                    } else {
                        String version = languageVersion.toString();
                        spec.setSourceCompatibility(version);
                        spec.setTargetCompatibility(version);
                    }
                }