This message was deleted.

any environment variable used during the configuration phase is tracked and becomes part of the CC cache key; a change to any of those tracked environment variables for subsequent builds represents a different configuration state, invalidating the CC cache. The trick is to understand what the env var represents and what the change between builds is (not familiar with that specific variable, oddly named though).

AFAIR, this environment variable is a peculiarity of the Java implementation of MacOS, retired as of Java 18. It may trip over configuration cache sometimes if a plugin or other build logic piece tries to read all environment variables at configuration time. A configuration cache report (

<root project>/build/reports/configuration-cache

, the exact path is printed when running gradle with

--info

) can be used to find out what exactly reads this environment variable. More context is in the issue https://github.com/gradle/gradle/issues/21224.

Evidently, my plugin was calling

System.getenv()

, which of course is interpreted as reading all the environment variables

Another options is to use a custom ValueSource, which allows you to do <whatever> as far as properties, env variables, file access, external executables go - so long as the result of the ValueSource is stable (a change to the final output invalidates CC). This is how

environmentVariablesPrefixedBy

and other related items are implemented. Depends on how complex your logic is (if its truly a simple env var lookup your approach will work fine).

Yeah, I've written a custom

ValueSource

once before, this is definitely easier. I still don't actually understand

ValueSourceParameters

ValueSourceParameters

would be inputs into your ValueSource; in the case of

environmentVariablesPrefixedBy

(

org.gradle.api.internal.provider.sources.EnvironmentVariablesPrefixedByValueSource

), its the prefix to search by. For custom value sources parameters may be say an API endpoint to invoke or something else that makes sense in the context of your custom logic.

I think the execution is more confusing than the core concept. You use all this generics-fu to

@Inject

a typed parameter list, which is morally equivalent not to dependency injection but to simple method arguments

ah yea. yes. too much ceremony/magic to model a … function call.

I've been on the other side of this kind of thing before

wowsers. did you make it out of that project OK?

It was actually pretty simple to use if you didn't think too hard about the type signature. It's basically just a feature that lets you chain together method calls

yep, the things we do to compensate for language limitations.

The advantage of type erasure in Java is (1) retroactive, binary-compatible generification, and (2) no runtime perf impact. The disadvantage is that they went totally nuts and ended up with something that is technically undecidable

lol. yep. an interesting “workaround” to maintain backwards compatibility that took a few twists…

Lest anyone misunderstand me, I think that type erasure was 100% the correct call, and furthermore I think Java's commitment to binary backwards compatibility is terribly underrated