skip to content

Catalog accessors return Provider types. What practical consequences does that laziness have, and when do you need `.get()` or `.asProvider()`?

level: seniorimportance: should knowfreq 35%

answer

  1. accessor = Provider, lazy
  2. dependencies has Provider overloads
  3. .get() for eager String version
  4. premature .get() hurts config cache
  5. thread Provider, get at last mile

basics

~20 s

Accessors are lazy Providers, so the value is computed on demand, not at script parse time. dependencies {} accepts the Provider directly; for APIs needing a plain value you call .get(). Use .asProvider() to get a library's dependency provider from a version-bearing accessor when needed.

solid answer

~50 s

Every catalog accessor returns a **`Provider`** — `libs.foo` is a `Provider<MinimalExternalModuleDependency>`, `libs.versions.z` a `Provider<String>`, etc. Laziness means the value isn't realized when the script is evaluated but when actually queried, which keeps configuration deferred and configuration-cache friendly. The dependency-handler methods (`implementation`, `api`, …) have **overloads that accept a `Provider`**, so you pass `libs.foo` straight in without `.get()`. You only call **`.get()`** when an API wants the eager value — e.g. a plain `String` version for a toolchain or a custom task input. There's a subtlety: a library alias that also carries a version exposes both `libs.foo` (the dependency provider) and `libs.foo.asProvider()` in some shapes, and a `libs.versions.x` accessor is a `Provider<String>` (call `.get()` for the String). Misusing `.get()` too eagerly (e.g. at configuration time inside a provider chain) can defeat laziness or break the configuration cache, so prefer passing Providers through and only `.get()` at the last mile.

code

kotlin · 5 lines
kotlin
dependencies {
    implementation(libs.guava)          // no .get() needed (Provider overload)
}

val kotlinVersion: String = libs.versions.kotlin.get()  // eager String

go deeper

for a junior

Know accessors aren't plain Strings and that you usually pass them in directly.

for a middle

Use .get() for raw version Strings and pass library/bundle accessors straight to configurations.

for a senior

Explain the lazy Provider model, the dependency-handler Provider overloads, and when premature .get() harms the config cache.

for a principal

Establish conventions (convention plugins, lazy provider threading) that keep large builds configuration-cache compatible while reusing catalog versions.

## Why Providers? Gradle's lazy configuration API models values as **`Provider<T>`**: a deferred computation that's only evaluated when its value is queried (ideally at execution time). Catalog accessors plug straight into this model — they are generated to return `Provider`s rather than realized objects. Types you'll meet: - `libs.guava` -> `Provider<MinimalExternalModuleDependency>` - `libs.bundles.net` -> `Provider<ExternalModuleDependencyBundle>` - `libs.plugins.boot` -> `Provider<PluginDependency>` - `libs.versions.kotlin` -> `Provider<String>` ## Passing Providers directly The `DependencyHandler` methods (`implementation`, `api`, `testImplementation`, …) have **overloads accepting a `Provider<? extends ...>`**. That's why this works with no `.get()`: ```kotlin dependencies { implementation(libs.guava) // Provider overload implementation(libs.bundles.net) // bundle Provider overload } ``` ## When you need `.get()` Call `.get()` only when an API needs the **eager** value and has no Provider overload — most commonly a raw version `String`: ```kotlin java { toolchain { languageVersion = JavaLanguageVersion.of(21) } } // pass a catalog version where a plain String is expected: val kotlinV: String = libs.versions.kotlin.get() ``` Eager `.get()` at configuration time is fine for simple reads, but inside a **provider chain** (`map`, `flatMap`) prefer keeping it lazy — calling `.get()` prematurely realizes the value too early and can hurt the **configuration cache** or task input tracking. ## `.asProvider()` and version manipulation Some accessor shapes expose `.asProvider()` to retrieve the underlying dependency `Provider` (useful when an accessor node also acts as a group). And because `libs.foo` is a Provider, you can build derived values lazily: ```kotlin dependencies { // constrain or transform lazily, staying configuration-cache safe implementation(libs.guava.map { it }) } ``` ## Configuration-cache angle Providers are central to the **configuration cache**: because the catalog accessor is a Provider, Gradle can serialize the deferred reference rather than a captured live object. Reaching into `.get()` and stashing the result in a field that crosses the config/execution boundary is where people accidentally break cacheability. Rule of thumb: **thread the Provider through; `.get()` at the very last mile.**

  • Why can you pass `libs.guava` to `implementation(...)` without `.get()`?
    Because `DependencyHandler` (and the configuration extension functions) provide overloads that accept a `Provider`, so Gradle resolves it lazily at the right time.
  • How can eager `.get()` interact badly with the configuration cache?
    Calling `.get()` and capturing the realized value into something serialized across the configuration/execution boundary defeats lazy evaluation and can produce config-cache problems or stale inputs; keeping the Provider deferred avoids that.
  • Where is `libs.versions.x` most commonly used?
    Inside the TOML via `version.ref` to share a version among libraries; the accessor (`Provider<String>`) is used in build logic when code needs the raw version, e.g. configuring a toolchain or a task argument.

saying these in an interview costs you the question

  • Claiming you must always call `.get()` to use an accessor in `dependencies {}` — the Provider overloads make that unnecessary.
  • Calling `.get()` eagerly everywhere, defeating laziness and risking configuration-cache breakage.

context

resolving links…