This message was deleted.

Yes, it does

Wow that's impressive. But I guess there's no real other way. Thanks for the insights!

If you look at the

--info

output when a new daemon is started, for example when using

--no-daemon

, you see that one of the daemon arguments is

-javaagent:...\.gradle\wrapper\dists\gradle-x.y-bin\...\gradle-x.y\lib\agents\gradle-instrumentation-agent-x.y.jar

Sounds like that could potentially be expensive? You'd have to visit/rewrite every class on the fly?

That's also the reason some builds break if they do dirty things like looking up some jar from the build script classpath and using it outside to start a separate process or similar. This then fails with missing classes, as the instrumented classes are used and then miss the injected Gradle classes.

Fair enough. Thanks for the details, as always! thank you

In any case I would strive for consistently accessing all such state through

layout...

and

providers...

. Then it's clearer for you and for Gradle what is part of the build configuration. E.g.:

layout.projectDirectory.file("....")
providers.environmentVariable("...")

(I think if it would have been my call, I would have used the instrumentation to forbidden

System.env

and such in future versions and direct everyone to a consistent API. But that's would have been a too drastic breaking change for Gradle I presume.)

That would be a horrible idea imho. The instrumentation is important for 3rd party libs you use in your build logic that you cannot gradlify. If such calls would simply be forbidden, you just couldn't use them anymore.

I guess. Although I am not sure if I want libraries reading state from "somewhere" without me knowing. But yes, you are right that it is quite common and probably unpractical because of that.

I wish this was a setting: • Warn (current) • Error (suggestion from Jendrik) • None (if I'm confident with my build and want to remove the associated overhead)

But would be nice to see this instrumentation etc being used in the future to generates reports of this. Then I can know where my build gets state from.

Shouldn't this be visible from CC report?