ARe there some known incompaitilbities with gradle configuration cache + project isolation + java17/21? This looks like all gradle internal things and I'm having trouble tracing it, not even fully sure what I'm looking for

> Configuration cache state could not be cached: field `spec` of `org.gradle.api.internal.tasks.execution.SelfDescribingSpec` bean found in task `:sub-project:compileJava` of type `org.gradle.api.tasks.compile.JavaCompile`: error writing value of type 'org.gradle.api.internal.tasks.compile.CompilerForkUtils$$Lambda$1793/0x00007f840c9dd898'
   > Unable to make field private final java.lang.Object[] java.lang.invoke.SerializedLambda.capturedArgs accessible: module java.base does not "opens java.lang.invoke" to unnamed module @6a825622

Can you show the full CC problem report?

Ah yeah sorry I'll update this thread when I can get that

Doesn't sound too strange to me. There are some objects that need to be serialized. Gradle has some internal magic that does it that uses some reflection. In Java the JPMS encapsulation is gradually increasing. In Java 11 some illegal access just showed a warning, with Java 17 and 21 those are hard errors. As project isolation is still experimental, I guess such things can happen, maybe you should report it if there is no issue yet. As a work-around, you can add the necessary

--add-opens

calls to the daemon JVM args.

Please file an issue, if this reproduces with recent Gradle

sure, I only have it as part of a functional test in the spdx-gradle-plugin, I'll have to narrow down the issue to a single part of the build.

I've had a quick look at the sources. Your stacktrace effectively complains that

--add-opens=java.base/java.net=ALL-UNNAMED

and

--add-opens=java.base/java.lang.invoke=ALL-UNNAMED

are missing from the daemon JVM args. And to me it looks like from a cursory look that this can only happen if Gradle thinks the daemon JVM will be < Java 9 so it does not add the necessary options while then indeed starting a Java 9+ JVM. When it then tries to serialize the CC state it fails due to the missing arguments. If you want to do a quick assessment, start you build with

--no-daemon --debug

and search for "Using daemon args:" in the output. I assume that there you will find that a Java 9+ is used but the

--add-opens

arguments are missing. You could then set a breakpoint in

DefaultDaemonStarter#startDaemon

and check what is happening. If my guess is right, then the

resolvedJava

will be set to a Java 9+ executable while the

majorJavaVersion

will be set to <= 8.

Cool thanks, I'll dig into it at some point (may be slow).