From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

The `ClassNotFoundException ... $1$$Lambda$1732/0x00000008012f8c40` part reminds me of issues serializing lambdas and `invokedynamic` (maybe <https://youtrack.jetbrains.com/issue/KT-46445/|this one>) but I was expected only the resolved provider value to be serialized to the CC, not the full provider chain?

~Looks like it's this one: <https://github.com/gradle/gradle/issues/22765>~ mm maybe not...

Bisect _seem_ to indicate <https://github.com/gradle/gradle/pull/26045/>

Small update here. I _think_ I have it cornered to:

 "GradleRunner with `withDebug(true)` doesn't install the intrumentation agent (<https://github.com/gradle/gradle/blob/8f7a2af8ddebb147c54b54ea1460f1b2a220f153/subprojects/core/src/main/java/org/gradle/internal/agents/DefaultClassFileTransformer.java#L47|this one>) and therefore the instrumentation that makes lambdas serializable is not called"

Does that ring a bell to anyone? I guess it used to work before instrumentations were made with transforms because the code path was different or so? Does that make sense?

Sounds strange.
`withDebug(true)` implicitly means that the test is executed in-process.
And that agent should already be available and active in the current process, shouldn't it?

Ah, maybe. The process is a test process. Where would the agent be installed?

I can see the daemon installs the agent <https://github.com/gradle/gradle/blob/3eda2dd72f9e01f26127f80d01047f4161c4b247/platforms/core-runtime/launcher/src/main/java/org/gradle/launcher/daemon/bootstrap/DaemonMain.java#L125|here>. But for a forked test JVM that calls `GradleRunner.foobar()` , I haven't seen a code path that sets the agent up yet.
Might 100% be missing something though, I'm pretty new to all this

Or does `java-gradle-plugin` configures the `Test` tasks to do so maybe :thinking_face: ?

Reproducer here: <https://github.com/martinbonnin/test-gradle-8-6>

Filed <https://github.com/gradle/gradle/issues/27956>

Ah, right, it is in-process in the test worker process, there the agent is most probably missing, yeah.

That probably also makes other problems like not recognizing configuration cache inputs which are otherwise also found by instrumented code.

And that already in older versions I'd assume

Thanks for the report, looks like a regression due to changes to instrumentation indeed

Hey <@UMCNY0BFH>, since  8.7 branching is scheduled for Monday (Feb 12th) and 8.7 RC1 is tentatively scheduled for a week after (Feb 19th) we decided to not do a patch release for 8.6.
I hope that doesn't block you in anyway

All good :+1: We'll stay on 8.5 until 8.7 RC.1 is out. There was nothing we particularly needed in 8.6, just keeping up to date