skip to content

How do the java.version property and encoding settings inherited from the parent affect the build, and how do you change the Java version?

level: middleimportance: should knowfreq 55%

answer

  1. java.version = parent-defined property
  2. Maps to maven.compiler.release
  3. No compiler-plugin block needed
  4. UTF-8 sourceEncoding = reproducible
  5. Property does nothing without the parent

basics

~10 s

The parent sets a default Java level and UTF-8 encoding. To compile for a different JDK, set <java.version>21</java.version> in your <properties>; that flows into the compiler plugin. UTF-8 encoding keeps builds identical across machines.

solid answer

~40 s

spring-boot-starter-parent defines a `java.version` property with a default value, and its inherited plugin configuration maps that property onto `maven-compiler-plugin` (via `maven.compiler.release`/`source`/`target`). So you don't configure the compiler plugin directly — you just set `<java.version>21</java.version>` in `<properties>` to target a specific JDK bytecode level. The parent also sets `project.build.sourceEncoding` and `project.reporting.outputEncoding` to **UTF-8**. That matters because, without an explicit encoding, Maven falls back to the platform default charset, which differs between machines/CI and can silently corrupt non-ASCII source and resource files. UTF-8 makes compilation and resource copying deterministic. Both are ordinary Maven property overrides, so a project can raise or lower them freely.

code

kotlin · 10 lines
kotlin
// pom.xml <properties> section (shown as comment):
//
// <properties>
//   <java.version>21</java.version>             // -> maven.compiler.release=21
//   <!-- UTF-8 already inherited from the parent; shown for clarity: -->
//   <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
// </properties>
//
// No <plugin> for maven-compiler-plugin is required:
// the parent's plugin management consumes java.version automatically.

go deeper

for a junior

Knows you set java.version to pick the Java level and that UTF-8 is used.

for a middle

Explains java.version is parent-defined and maps to the compiler release, and why UTF-8 = reproducible builds.

for a senior

Distinguishes compile target from the running JDK and knows the property is inert without the parent.

for a principal

Considers toolchains, reproducible-build guarantees, and the migration implications when dropping the parent.

## The java.version property `java.version` is **not** a standard Maven property — it's one **defined by spring-boot-starter-parent**. The parent's build configuration wires it into the `maven-compiler-plugin` so that setting it controls the compiled bytecode target. In modern Spring Boot it maps to `maven.compiler.release` (the `--release` javac flag), which sets source level, target level, and the platform API in one go; older versions mapped it to `maven.compiler.source`/`maven.compiler.target`. To change the Java level you simply override the property: ```xml <properties> <java.version>21</java.version> </properties> ``` You do **not** need a `<plugin>` block for `maven-compiler-plugin` — the parent already configured it; your property just feeds it. (You *can* still configure the compiler plugin directly, e.g. to add `-parameters` or annotation processors, and Spring Boot's parent already enables `-parameters` by default.) ## Encoding The parent sets two properties: - `project.build.sourceEncoding` = `UTF-8` — used by the compiler and resource plugins when reading source and resource files. - `project.reporting.outputEncoding` = `UTF-8` — used by reporting plugins. ### Why it matters If encoding is unset, Maven emits the well-known warning *"Using platform encoding ... to copy filtered resources, i.e. build is platform dependent!"* and uses the JVM default charset (`file.encoding`), which may be `windows-1252` on Windows, `UTF-8` on Linux, etc. That non-determinism can corrupt characters in `.java` files, `messages.properties`, templates, etc. Pinning UTF-8 makes the build **reproducible** across developer machines and CI runners. ## Gotchas - Overriding `java.version` changes only the **compile target**. It does **not** change the JDK you run Maven with. If you set `<java.version>21</java.version>` but run Maven on JDK 17, compilation fails — the toolchain/JDK must be new enough. - Because `java.version` is parent-defined, it silently does nothing if you're **not** using the parent (e.g. you switched to the BOM import). Then you must configure `maven-compiler-plugin` (or `maven.compiler.release`) yourself. - Encoding also governs **resource filtering**: filtered files are read/written using `project.build.sourceEncoding`.

  • If you set <java.version>21</java.version> but run Maven with JDK 17, what happens?
    The build fails at compilation. java.version only sets the target bytecode/release level; the JDK actually running Maven must support that release, so you need JDK 21 (or a configured toolchain).
  • What breaks about java.version if you migrate off the parent to the BOM import?
    The property is parent-defined, so it silently stops controlling the compiler. You must set maven.compiler.release (or configure maven-compiler-plugin) yourself.

saying these in an interview costs you the question

  • Adding a full maven-compiler-plugin block when java.version already suffices
  • Thinking java.version selects the JDK Maven runs on
  • Assuming encoding doesn't matter because 'it works on my machine'

context

resolving links…