All 15 Build Tools: Maven & Gradle questions
More in Build Tools: Maven & Gradle
What is the difference between Maven's <dependencies> scope values (compile, provided, runtime, test) and how do they affect what's included in the final packaged artifact? How do you resolve a dependency version conflict manually in Maven using exclusions, and when would this be necessary despite the automatic nearest-wins resolution? What is a Maven BOM (Bill of Materials), and how does it help manage consistent dependency versions across a multi-module project or organization? How do you manage different configurations for different environments (development, staging, production) using Maven profiles or Gradle's equivalent mechanisms? How does Maven's dependency resolution algorithm handle transitive dependency version conflicts, and what is the "nearest definition wins" rule? How does Gradle's incremental build and build cache mechanism achieve significantly faster rebuild times compared to Maven's default behavior? How would you configure a multi-module Maven or Gradle project, and what benefits does modularizing a large codebase this way provide? How would you write a custom Maven plugin or Gradle task to perform project-specific build automation not covered by existing plugins? How would you configure a Maven or Gradle build to produce a reproducible build (bit-for-bit identical output given the same source), and why does this matter for supply chain security? How would you configure a Maven or Gradle build to produce a shaded/fat JAR containing all dependencies bundled into a single executable JAR file?
Advertisement
Back to results for “Java Fundamentals: Syntax”
Java › Build Tools: Maven & Gradle

How do you configure the Maven Compiler Plugin to target a specific Java language version, and what's the difference between source, target, and release configuration?

Intermediate

Answer

The maven-compiler-plugin's <source> and <target> properties independently control the Java language level accepted by the compiler and the bytecode version produced respectively (historically requiring both to be set consistently); the newer <release> property (Java 9+) is preferred since it sets both simultaneously AND ensures the compiler checks against the correct API surface for that specific version (preventing accidental use of APIs only available in a newer JDK than the target, which source/target alone don't fully guard against).
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
        <release>17</release>  <!-- preferred over separate source/target -->
    </configuration>
</plugin>
Real-world example A team building with JDK 21 installed but targeting Java 17 compatibility for their deployed environment uses <release>17</release>, which correctly rejects any accidental usage of a Java 18+ only API, an error that using only <source>17</source><target>17</target> might not have caught.

Common follow-ups: What error occurs if you compile with a newer JDK using an API not available in your target release, and how does <release> specifically catch this?;What's Gradle's equivalent sourceCompatibility/targetCompatibility versus toolchain configuration?

Java Fundamentals: Syntax Data Types & Operators;Deploy Checklist
All 15 Build Tools: Maven & Gradle questions