skip to content

What does applying the core `java` plugin give you in a Gradle build?

level: juniorimportance: must knowfreq 78%

answer

  1. main + test source sets
  2. compileJava / test / jar tasks
  3. applies base, wires assemble/check/build
  4. implementation/compileOnly/runtimeOnly configs
  5. java {} extension + toolchain

basics

~10 s

The java plugin adds the main and test source sets, compile tasks (compileJava, compileTestJava), processResources, the jar task, and the standard build/check/assemble lifecycle wiring.

solid answer

~30 s

Applying `id("java")` bootstraps a conventional JVM project. It creates the `main` and `test` **source sets** (with default layout `src/main/java`, `src/test/java`, plus matching `resources` dirs), and registers their tasks: `compileJava`, `processResources`, `compileTestJava`, `processTestResources`, `test`, and `jar`. It wires these into the lifecycle plugin's tasks so `assemble` builds the jar, `check` runs `test`, and `build` does both. It also adds the standard dependency **configurations** (`implementation`, `compileOnly`, `runtimeOnly`, `testImplementation`, etc.) and a `java {}` extension for things like `sourceCompatibility` and `toolchain`. In short, it's the baseline that turns an empty project into a compilable, testable, packageable JVM module.

code

kotlin · 14 lines
kotlin
plugins {
    java
}

java {
    toolchain {
        languageVersion.set(JavaLanguageVersion.of(21))
    }
}

dependencies {
    implementation("com.google.guava:guava:33.0.0-jre")
    testImplementation("org.junit.jupiter:junit-jupiter:5.10.0")
}

go deeper

for a junior

List the headline outputs: main/test source sets, compileJava/test/jar tasks, the build lifecycle.

for a middle

Add that it applies base, contributes the standard configurations, and exposes the java {} extension and toolchain.

for a senior

Explain the convention-over-configuration philosophy and how source-set outputs feed jar and downstream consumers.

for a principal

Frame it as the foundation other JVM plugins (java-library, application) build on, and how you'd standardize toolchains across a multi-module org via a convention plugin.

## What the `java` plugin is The `java` plugin is one of Gradle's **core JVM language plugins**. Applying it transforms a bare project into a conventional Java module by contributing source sets, tasks, configurations, and an extension — all by convention so you don't wire them by hand. ## Source sets A **source set** is a named, logical group of source files compiled and processed together. The `java` plugin creates two: - `main` — production code at `src/main/java` (+ `src/main/resources`) - `test` — test code at `src/test/java` (+ `src/test/resources`) Each source set has an associated output (compiled classes + processed resources) and its own dependency configurations. ## Tasks it registers | Task | Role | |------|------| | `compileJava` | compile `main` Java sources | | `processResources` | copy `main` resources to output | | `classes` | aggregate: depends on `compileJava` + `processResources` | | `compileTestJava` / `processTestResources` / `testClasses` | same, for `test` | | `test` | run the unit tests | | `jar` | package `main` output into a jar under `build/libs` | ## Lifecycle wiring The `java` plugin applies the `base` plugin under the hood, then hooks its tasks into the lifecycle: `assemble` → `jar`, `check` → `test`, `build` → `check` + `assemble`. ## Configurations and extension It adds dependency configurations (`implementation`, `compileOnly`, `runtimeOnly`, `annotationProcessor`, and the `test*` variants) and a `java {}` extension where you set `sourceCompatibility`, `targetCompatibility`, or a toolchain. ```kotlin plugins { java } java { toolchain { languageVersion.set(JavaLanguageVersion.of(21)) } } dependencies { implementation("com.google.guava:guava:33.0.0-jre") testImplementation("org.junit.jupiter:junit-jupiter:5.10.0") } ``` ## Why it matters Nearly every JVM build sits on top of this plugin (directly, or via `java-library`/`application`, which themselves apply `java`). Knowing what it provides explains where tasks like `compileJava` and `jar` come from without you ever declaring them.

  • Where does the produced jar land by default?
    Under `build/libs/<project>-<version>.jar`; the `jar` task and the `base` plugin's `archivesName`/`libsDirectory` control the name and location.
  • Does the `java` plugin apply any other plugin?
    Yes — it applies the `base` plugin, which provides the `clean`, `assemble`, `check`, and `build` lifecycle tasks plus archive conventions.

saying these in an interview costs you the question

  • Claiming the `java` plugin adds an `implementation` configuration that leaks onto consumers' compile classpath (that's `java-library`'s `api`).
  • Saying it provides a `run` task — that's the `application` plugin.

context

resolving links…