This message was deleted.

They need to be "isolatable", which means Gradle needs to be able to ensure that the values can be safely used in parallel. If Gradle knows the value is immutable, it will use the value as-is. Otherwise, Gradle will make a copy. For some types, for example

ArrayList

or

Provider<T>

it knows how to do this efficiently. For everything else, it will just serialize the value.

Is there some annotation I can use to make Gradle use the value as-is? Can I somehow convey that the inputs and outputs are thread-safe?

Is there some annotation I can use to make Gradle use the value as-is?

There is not. We're not super keen on adding such a thing, as it's pretty error prone, but it's certainly an option. Do you have an example of a type you'd like to opt-in, where serialization is problem?

Do you have an example of a type you'd like to opt-in, where serialization is problem?

@adam I have to integrate with a legacy build system that runs an external process to find, start (if necessary), and connect to a localhost daemon. This is proving quite difficult to do in a way that is compatible with configuration caching

So you have to use the

ValueSource

because of the external process, right? Is this process/connection used at configuration time? I'm asking because this is sometimes a proxy for "start the process always regardless of which tasks are being invoked", and a better API can be designed for that use case.

Yes, configuration time