skip to content

Besides the configuration cache, what other build feature does BuildFeatures expose, and how would you introspect it for diagnostics?

level: middleimportance: nice to knowfreq 18%

answer

  1. isolatedProjects alongside configurationCache
  2. same requested/active shape
  3. serviceOf<BuildFeatures>()
  4. telemetry of performance modes
  5. branch on active

basics

~10 s

BuildFeatures also exposes isolatedProjects, with the same requested/active Provider<Boolean> pair. You introspect it the same way: gradle.serviceOf<BuildFeatures>().isolatedProjects.active.getOrElse(false).

solid answer

~40 s

`BuildFeatures` exposes more than the configuration cache: it also surfaces **Isolated Projects** via `buildFeatures.isolatedProjects`, which has the identical `BuildFeatureValue` shape — `requested: Provider<Boolean>` and `active: Provider<Boolean>`. Isolated Projects is an opt-in performance feature (an extension of the configuration-cache model) that isolates each project's configuration for safer parallelism. For diagnostics you read it exactly like the configuration cache: obtain `BuildFeatures` via injection or `gradle.serviceOf<BuildFeatures>()`, then `isolatedProjects.requested.getOrElse(false)` / `.active.getOrElse(false)`. A common use is build telemetry that records which performance modes a given CI invocation actually ran under, so you can correlate timings with feature state across the fleet. As with the configuration cache, branch real behaviour on `active`, not `requested`.

code

kotlin · 7 lines
kotlin
val f = gradle.serviceOf<BuildFeatures>()
listOf(
    "configuration-cache" to f.configurationCache,
    "isolated-projects" to f.isolatedProjects,
).forEach { (name, feat) ->
    logger.lifecycle("$name requested=${feat.requested.getOrElse(false)} active=${feat.active.getOrElse(false)}")
}

go deeper

for a junior

Name isolatedProjects as the other feature with the same requested/active shape.

for a middle

Show the serviceOf access and getOrElse reads, noting the uniform contract.

for a senior

Explain how the uniform shape enables generic per-feature telemetry of requested vs active.

for a principal

Frame BuildFeatures as the single supported introspection door for opt-in performance features, enabling fleet-wide mode reporting.

## BuildFeatures is feature-agnostic The service is intentionally a *registry* of opt-in build features, not a config-cache-only API. Today it exposes two: ``` interface BuildFeatures { val configurationCache: BuildFeatureValue val isolatedProjects: BuildFeatureValue } ``` Both use the same `BuildFeatureValue { requested; active }` contract, so once you understand one you understand the other. ## Isolated Projects in one paragraph Isolated Projects is an opt-in feature that isolates the configuration of each project from the others, building on the configuration-cache machinery to unlock more aggressive parallelism and faster IDE sync on large multi-project builds. You don't need its internals here; what matters for this leaf is that `BuildFeatures` lets you *introspect* its state without touching internal APIs. ## Introspecting it ```kotlin import org.gradle.api.configuration.BuildFeatures import org.gradle.kotlin.dsl.serviceOf val features = gradle.serviceOf<BuildFeatures>() val ip = features.isolatedProjects logger.lifecycle( "isolated-projects requested=${ip.requested.getOrElse(false)} " + "active=${ip.active.getOrElse(false)}" ) ``` Same access patterns, same `getOrElse(false)` discipline for the possibly-absent `requested` provider, same rule that behavioural branching uses `active`. ## Why a single uniform API matters Because every feature shares the `requested`/`active` shape, generic diagnostics or build-scan-style telemetry can iterate over features uniformly: capture both flags per feature, attach them to your invocation record, and you get a consistent picture of what performance modes were requested vs effective. This uniformity is the design intent of `BuildFeatures` — one supported door for all opt-in feature introspection.

  • Does isolatedProjects use a different access pattern than configurationCache?
    No — both are BuildFeatureValue with requested/active Providers, accessed identically via injection or serviceOf.
  • Why is the uniform requested/active shape useful?
    Generic telemetry can iterate over all features uniformly, recording requested-vs-active per feature for consistent build diagnostics.

saying these in an interview costs you the question

  • Thinking BuildFeatures only knows about the configuration cache.
  • Assuming Isolated Projects has a different introspection API.
  • Branching behaviour on requested for Isolated Projects too — still use active.

context

resolving links…