# Provider

@NonExtensible
interface Provider<T>

A container object that provides a value of a specific type. The value can be retrieved using one of the query methods such as get or getOrNull.

A provider may not always have a value available, for example when the value may not yet be known but will be known at some point in the future. When a value is not available, isPresent returns `false` and retrieving the value will fail with an exception.

A provider may not always provide the same value. Although there are no methods on this interface to change the value, the provider implementation may be mutable or use values from some changing source. A provider may also provide a value that is mutable and that changes over time.

A provider may represent a task output. Such a provider carries information about the task producing its value. When this provider is attached to an input of another task, Gradle will automatically determine the task dependencies based on this connection.

A typical use of a provider is to pass values from one Gradle model element to another, e.g. from a project extension to a task, or between tasks. Providers also allow expensive computations to be deferred until their value is actually needed, usually at task execution time.

There are a number of ways to create a Provider instance. Some common methods:

- A number of Gradle types, such as Property, extend Provider and can be used directly as a provider.
- Calling map to create a new provider from an existing provider.
- Using the return value of register, which is a provider that represents the task instance.
- Using the methods on org.gradle.api.file.Directory and org.gradle.api.file.DirectoryProperty to produce file providers.
- By calling provider or provider to create a new provider from a Callable.

For a provider whose value can be mutated, see Property and the methods on org.gradle.api.model.ObjectFactory.

Note: This interface is not intended for implementation by build script or plugin authors.

## Configuration Cache

The Configuration Cache handles providers in a special way. When a provider is discovered to be part of the cached build configuration (e.g. when it is a task input), one of two things happen:

- Cache by value. The value of the provider is computed and stored. This typically happens if the provider is derived from purely configuration-time data.
- Cache by computation. The provider is stored as a lazy computation. For example, if the provider is a result of map, then the origin provider (on which `map` was called) and the `Transformer` (including its captured variables) are stored. Note that the origin provider may still be cached by value. After loading from cache, the value is only computed if requested (e.g. with get), as usual. This typically happens when the value of the provider is only available at execution time (e.g. derived from a task output) or if it is sourced from the environment (e.g. a system property or an environment variable).

The Configuration Cache operates under the assumption that most of the stored providers will be used at execution time, so it attempts to cache values of as many providers as possible without introducing more build configuration inputs. However, the exact definition of which provider to cache is intentionally left underspecified. For example, even a provider derived from a system property provider may be cached by value if that system property is already an input.

Following the rules below ensures that your Providers remain configuration-cache compatible regardless of applied optimizations.

1. Providers returned by provider or provider are always computed at configuration time. The `Callable` may capture arbitrary data types and freely call configuration-time-only APIs. This is the preferred way to bridge non-lazy and lazy APIs, like passing getVersion into task's input Property.
2. Any value returned (provided) by the provider must conform to the configuration cache requirements. This requirement may not be enforced when the value is an intermediate result and the Configuration Cache runs the computation chain to cache the end result.
3. Any value captured by the computation of the provider (e.g. a variable captured by the `Transformer` lambda supplied to map) must conform to the configuration cache requirements, except the `Callable` of provider or provider. This requirement may not be enforced when the Configuration Cache runs the computation chain containing non-conforming transformation to cache the end result.
4. The computation of the provider (except the `Callable` of provider or provider) should not invoke configuration-time only APIs. This requirement may not be enforced when the Configuration Cache runs the computation chain containing non-conforming transformation to cache the end result.
5. The computation of the provider should not use external state (read system properties, environment variables, or files) to avoid introducing accidental build configuration inputs. Preferably, these should be obtained through providers returned by ProviderFactory and zip should be used to mix them into the computation chain. The `Callable` of provider or provider must ignore this requirement if the external state is used by configuration-time-only API because adding an input is unavoidable in this case.

Configuration Cache's support of providers that do not conform to these requirements is unspecified and may change between Gradle versions or depending on when values of the providers are obtained during build.

Some providers returned by Gradle APIs provide types that cannot be configuration-cached, for example TaskProvider or `Provider<Configuration>`. Such providers should not be used as part of the cached build configuration directly, but the providers returned by their map or flatMap can be if their value or the downstream transformation chain conforms to the requirements above. In most cases it is also safe to add these non-cacheable providers to ConfigurableFileCollections when it makes sense.

#### Since

4.0

#### Parameters

<T>

Type of value represented by provider

#### Inheritors

BinaryProvider
NamedDomainObjectProvider
ListProperty
SetProperty
MapProperty
Property

## Functions

filter
Link copied to clipboard
@Incubating
abstract fun filter(spec: Spec<in T>): Provider<T>
Returns a new Provider with the value of this provider if the passed spec is satisfied and no value otherwise.
flatMap
Link copied to clipboard
abstract fun <S> flatMap(transformer: Transformer<out @Nullable Provider<out S>, in T>): Provider<S>
Returns a new Provider from the value of this provider transformed using the given function.
get
Link copied to clipboard
abstract fun get(): T
Returns the value of this provider if it has a value present, otherwise throws `java.lang.IllegalStateException`.
getOrElse
Link copied to clipboard
abstract fun getOrElse(defaultValue: T): T
Returns the value of this provider if it has a value present.
getOrNull
Link copied to clipboard
@Nullable
abstract fun getOrNull(): @Nullable T
Returns the value of this provider if it has a value present.
isPresent
Link copied to clipboard
abstract fun isPresent(): Boolean
Returns `true` if there is a value present, otherwise `false`.
map
Link copied to clipboard
abstract fun <S> map(transformer: Transformer<out @Nullable S, in T>): Provider<S>
Returns a new Provider whose value is the value of this provider transformed using the given function.
orElse
Link copied to clipboard
abstract fun orElse(value: T): Provider<T>
Returns a Provider whose value is the value of this provider, if present, otherwise the given default value.
abstract fun orElse(provider: Provider<out T>): Provider<T>
Returns a Provider whose value is the value of this provider, if present, otherwise uses the value from the given provider, if present.
zip
Link copied to clipboard
abstract fun <U, R> zip(right: Provider<U>, combiner: BiFunction<in T, in U, out @Nullable R>): Provider<R>
Returns a provider which value will be computed by combining this provider value with another provider value using the supplied combiner function.