This message was deleted.

I wouldn't integrate Kythe with Gradle that way (despite that being what the Kythe doc says), it probably worked with older versions of Gradle, but no longer. Something you could try:

tasks.withType(JavaCompile).configureEach {
    doFirst {
        exec {
            executable '/opt/kythe/extractors/javac-wrapper.sh'
            args options.allCompilerArgs
            environment 'KYTHE_EXTRACT_ONLY', true
        }
    }
}

(be careful if you use toolchains, you'd have to also set the

JAVA_HOME

environment variable) I think it would be much better as an individual task but that

doFirst

should work as a POC.

I don't think the original suggestion is bad. I think that's a case for which

forkOptions.executable

exists. But I also noticed that it clashes with the newer toolchain integration nowadays. @Matan Sabag I think adding this fixes the issue:

javaCompiler.convention(null as JavaCompiler?)

At some point before Gradle 7.6 passing an arbitrary executable to the

executable

property stopped being supported. For

compileJava

the property is intended to accept a path to a valid

javac

that is a part of a valid JDK installation. In other words, a toolchain was inferred from this path, and then used. Starting from Gradle 8.0, toolchains become the main and only way of configuring executables for core JVM tasks. Previously, toolchain tool properties such as

javaCompiler

were optional/nullable. With Gradle 8.0 a tool (a compiler in this case) will always be present, and setting it to null will lead to errors.

@Thomas Broyer - It seems to work, thanks! I will also give it a try with tool chains and see how it works. @Jendrik Johannes - This didn’t work..not sure why but I get the same error

@Alex Semin I just wanted to demonstrate (see the video) that you can set the "executable" as one option to make the JavaCompile task fork a separate process. It did not work without doing this (but maybe that is because I also configured a toolchain).

I guess the problem here is that

javac-wrapper.sh -version

, as called by default by Gradle to determine the Java version of the toolchain, does nothing (possibly fails). One possibility is to change the script to make it work, or ditch the script and do that same in pure Gradle (more or less what I proposed)

That makes sense. Thanks for the explanation @Thomas Broyer.

@Jendrik Johannes The executable option availability and usage in Gradle 8.0 is unchanged compared to Gradle 7

Thanks for clarifying. I misunderstood then. Can you elaborate (or link some docs) about what the practical consequences of this are then:

Starting from Gradle 8.0, toolchains become the main and only way of configuring executables for core JVM tasks.

@Jendrik Johannes Mainly that toolchain-related properties on the tasks, such as

CompileJava.javaCompiler

are not optional anymore, and it’s not possible to set them to null. Previously, not all core JVM tasks were using toolchains in all cases. With Gradle 8.0 even if you configure

executable

or

javaHome

, they will resolve into a toolchain.

But didn't you just said behavior will not change compared to Gradle 7?

But didn’t you just said behavior will not change compared to Gradle 7?

I was referring to the

executable

setting in the

compileJava

task specifically. There, nothing is really changed apart from the fact that

javaCompiler

property will be set whatever toolchain is configured via the

executable

. Previously, the

javaCompiler

would keep having the

null

value if you query it.

Oh, so you can set

executable

and the

javaCompiler

will be calculated from the

exectuable

value?

Currently you can set an

executable

and do

javaCompiler.set(provider { null })

to make the

executable

be used.

@Vampire I am not sure I understand what you mean. It should be enough to set

options.fork = true

and

options.forkOptions.executable

, no need to nullify the compiler property. Unless the toolchain is configured on the

java

extension as well.

Yes, if you currently have a toolchain in the

java

extension but need a task to use a different executable. Then you currently need to set the

executable

and additionally set the Java tool property to a

null

-producing provider otherwise the

executable

is ignored.

You can find more technical details for this change here: https://github.com/gradle/gradle/pull/22108

Yes, and it will override the toolchain configured on the

java

extension as well (Starting with Gradle 8.0)

You set an

executable

for one specific task and that will set the toolchain of the whole Java extension? o_O I don't think I like that change. Seems the worng way around.

You set an

executable

for one specific task and that will set the toolchain of the whole Java extension? o_O

Sorry to confuse you. It will override the toolchain for the task. The extension-level toolchain stays untouched. I mean the “override” in a sense of priority of what gets selected for the task in the end.

Ah, ok, then it sounds perfect, thanks for the clarification. :-)

Thanks for explaining @Alex Semin. Makes sense and sounds like a great unification/simplification in this area.