skip to content

In IntelliJ IDEA, what is the difference between delegating build/run to Gradle versus using the IDE's own build, and what are the trade-offs?

level: middleimportance: must knowfreq 60%

answer

  1. delegate = run real Gradle tasks
  2. native = IntelliJ compiler/runner
  3. parity vs speed
  4. codegen/processResources skipped in native
  5. works-in-IDE-fails-in-CI

basics

~20 s

Delegate-to-Gradle runs builds and tests through Gradle tasks, so behavior matches CI and honors all Gradle config. The IDE's native builder compiles with IntelliJ's own compiler and is often faster but can diverge from Gradle (custom tasks, processing, resources).

solid answer

~50 s

IntelliJ offers two modes for *Build and run using*: **Gradle** (delegate) or **IntelliJ IDEA** (native). - **Delegate to Gradle**: when you build or run a test, IDEA invokes the actual Gradle tasks (`compileJava`, `test`, etc.) via the Tooling API. You get behavior **identical to the command line and CI**: annotation processors, custom source generation, resource filtering, `processResources`, and custom tasks all run. Cost: slower startup, and you depend on Gradle's up-to-date checks. - **IDE native build**: IntelliJ compiles using its own incremental compiler and runs tests through its runner, bypassing Gradle's task graph. Often faster for tight edit-compile loops, but it can **diverge** — generated sources, custom Copy/processing tasks, or non-standard source sets may not be produced, causing 'works in Gradle, fails in IDE' (or vice versa). Rule of thumb: prefer Gradle delegation for correctness/parity (especially with codegen or custom tasks); use native build only when you understand the gaps and want speed.

code

text · 3 lines
text
Settings -> Build Tools -> Gradle:
  Build and run using : [Gradle | IntelliJ IDEA]
  Run tests using     : [Gradle | IntelliJ IDEA]

go deeper

for a junior

Know the two modes exist and that delegating to Gradle matches the command line.

for a middle

Explain the trade-off (parity vs speed) and name concrete divergences: codegen, processResources, custom tasks, custom source sets.

for a senior

Diagnose works-in-IDE/fails-in-CI from the build mode; reason about up-to-date checks and the cache only applying to delegated builds.

for a principal

Set team defaults (delegate-to-Gradle for correctness) and weigh developer-loop speed vs reproducibility across a large org.

## The setting In IntelliJ, **Settings → Build, Execution, Deployment → Build Tools → Gradle** has *Build and run using* and *Run tests using*, each set to either **Gradle** or **IntelliJ IDEA**. ## Delegate to Gradle (parity mode) With delegation on, pressing *Build* or running a test makes IDEA call the corresponding **Gradle tasks** through the Tooling API — the same `:app:compileJava`, `:app:test`, `:app:processResources`, etc. that the CLI runs. **Pros** - **Fidelity to CI**: whatever Gradle does on the command line happens in the IDE — annotation processing, `processResources` filtering, custom `Copy`/codegen tasks, custom source sets. - Honors Gradle's **up-to-date** checks and the **build cache**. - One source of truth for compiler args, toolchains, and dependencies. **Cons** - Slower turnaround: Gradle invocation + task-graph configuration adds overhead per build. - Errors surface as Gradle task failures, which some find noisier. ## IDE native build (speed mode) With *IntelliJ IDEA* selected, the IDE uses its **own incremental Java compiler** and test runner, driven by the **module model produced at sync time**. It does not run Gradle tasks for a normal build. **Pros** - Fast incremental compilation, great for tight loops. **Cons / divergence risks** - **Generated sources** from custom tasks may be missing or stale because the generating task never ran. - **Resource processing** (token replacement, `expand`, filtering) done by `processResources` is skipped, so runtime config can differ. - Custom **source sets** or non-conventional layouts may not be wired the same way. - Net effect: subtle 'passes in IDE, fails in CI' bugs. ## How sync ties in Either way, the IDE first needs an accurate **model from sync**. Native build relies *entirely* on that model being correct; if a generating task feeds the classpath, you may need at least one Gradle build (or task run) so the outputs exist before native compilation can see them. ```text Delegate : IDE --Tooling API--> Gradle tasks (compileJava, test, processResources, custom) Native : IDE compiler/runner uses sync model (skips Gradle task execution) ``` ## Practical guidance - Codegen, custom tasks, resource filtering, or strict CI parity → **delegate to Gradle**. - Plain Java/Kotlin module, speed-critical loop, you know there are no special tasks → native can be acceptable. - When 'it works in the IDE but not on the command line' appears, switching to Gradle delegation is the first diagnostic.

  • A test passes in IntelliJ but fails on the command line. What's a likely cause tied to this setting?
    The IDE is on native build and skipped a Gradle task (e.g. codegen or processResources/resource filtering) that the CLI runs. Switching 'Run tests using' to Gradle restores parity.
  • Does native build still benefit from Gradle's build cache?
    Not for the compile/test step — native build uses IntelliJ's own incremental compiler and bypasses Gradle's task execution and cache; only delegated builds use the Gradle cache.

saying these in an interview costs you the question

  • Claiming native build runs the same tasks as Gradle — it bypasses the task graph.
  • Assuming native build always produces generated sources / processed resources.

context

resolving links…