This message was deleted.

Afair worker api even with process isolation does not have support for toolchains directly. Could be worth a feature request though. 😉 But as you can set the

executable

in the

forkOptions

, you could set that to a toolchain executable like

forkOptions.executable = "${javaToolchains.launcherFor { languageVersion = JavaLanguageVersion.of(21) }.get().executablePath}"

or something similar. If you want to use worker api, you should not use

JavaExec

at all, why should you? Or what do you actually try to achieve?

Well, we need to run our compiler (sqldelight) in a separate classpath and also multiple actions in parallel, sounds like the best use-case for the worker api, that we currently use. But the recent update of the compiler (intellij) forces us to use a JVM 17. because we already use a separate classpath, it should be doable to use the toolchain to not require JVM 17 for the gradle plugin as a JVM requirement for the users, but only use it for our tasks. And due the missing toolchain support of the worker api, the only workaround I know is JavaExec 🤔

Definitely. as I said, it should work like I showed it above in the snippet. That was from within

processIsolation { ... }

. It is just not as convenient as if it had proper support.

Ohh, nice, thanks for the info, will try it! Sure, some shortcut would be nice though.

I'm not sure, because I did not really get what you are saying. 😄 If you want to compile sources with different Java versions, you usually need different source sets or different feature variants. But we did not talk about compiling code here at all, did we?

We have a module which requires Java 17, and our Gradle plugin uses some code of this module in the worker action, so the Java 17 classes are used in the same complications as the Gradle plugin. But maybe there is another workaround: Create a Java 8 variant of the module, and consume this variant as compileOnly by the Gradle plugin. During runtime, the Gradle plugin fetches the JVM 17 variant. Open question: Which jvm is used to consume the submit(WorkerAction) { setup... }?

// This needs to be Java 8
workerExecutor.processIsolation {
      it.classpath.from(classpath)
      it.forkOptions {
        it.executable = jvmToolchain.launcherFor {
          it.languageVersion.set(JavaLanguageVersion.of(17))
        }.get().executablePath.toString()
      }
    }.submit(GenerateInterfaces::class.java) {
// This needs to be Java 17
    }

And can you explicitly declare the JVM attribute of a configuration?

No, that is configuration that is done in the parent Gradle process. The point would be that you do not use the Java 17 stuff in there, but only do the Java 17 stuff in the separate work action that is executed on the worker daemon

Ah wait, you are right, I mixed it up. Of course the setup does not need to use Java 17, but the WorkerAction... But the worker action will be in the same Java module as the Gradle plugin, so I need to create a stub Java 8 dependency used during compiling the Gradle plugin and a Java 17 actual variant used by the WorkerAction in the isolated process.

Or you seperate the worker action into a different project or source set or feature variant, so that you can compile it with Java 17 independently of your remaining plugin code, as I said. 🙂

But how do you configure the worker action?

?

If you separate the worker action and compile it with Java 17, you need to pass the WorkerAction class in the

submit

call, which is used by Java 8.

Hm, right, actually never did such a setup myself so far. You probably have the

WorkAction

as part of the plugin code, get an

ExecActions

injected that then uses

javaExec

to execute the Java 17 code? And you can remove

processIsolation

then. Or you indeed need some Java 8 stubs to compile against and have the Java 17 code for runtime.