Explain Codes LogoExplain Codes Logo

Specifying Java version in Maven - differences between properties and compiler plugin

java
maven-compiler-plugin
java-version
pom-xml
Anton ShumikhinbyAnton Shumikhin·Nov 23, 2024
TLDR

To effectively set the Java version in your Maven project, you configure the <java.version> in your <properties> and align the <maven-compiler-plugin>. This ensures your code compiles and runs with the exact Java version you've specified:

<properties> <java.version>11</java.version> <!-- or your desired version, but it has to be greater than 1. --> </properties> <build> <plugins> <plugin> <artifactId>maven-compiler-plugin</artifactId> <configuration> <release>${java.version}</release> <!-- Maven's special sauce for version compatibility --> </configuration> </plugin> </plugins> </build>

Leveraging the <release>parameter targets the specific Java platform version, with Maven handling both source and target settings under the hood — that's Maven doing all the heavy-lifting for you!

Essential settings explained

Knowing the default settings of Maven

This is an under-the-hood key feature of Maven’s complier plugin: it assigns default source and target versions according to either the plugin version or, if not referenced, the Maven defaults. If you skip this step, your build may unintentionally use antiquated Java language features by default, leading to compatibility hiccups with runtime environments that expected all-new versions.

JAVA_HOME, compatibility, and you!

The JAVA_HOME environment variable is the “home base” of your build process; it should match the JDK version mentioned in your POM. If JAVA_HOME in your system points at a different JDK version than you just specified on your pom.xml, then Maven will default to using JAVA_HOME, which can lead to surprising twists in builds and execution.

Multi-module project approach

Your build consistency is important, right? For multi-module projects, specify the Java version within the parent POM! This helps maintain a consistent compilation across all modules and prevent the chaos of different modules compiled with varying Java versions, creating unforeseen runtime discrepancies.

Keep your IDE and Maven on the same page

Don’t forget to reload your project in the IDE after updating the Java version within that pom.xml file. By doing this, you keep the Maven configuration changes synchronized, preventing potential conflicts between the IDE's cached settings and the Maven build settings. Pay special attention if you're a dedicated fan of IntelliJ IDEA and other IDEs with Maven integration.

Thinking ahead in cross-compilation

For bootstrap and release options, you might also need to specify --release parameter to ensure that you are not just compiling for specific JDK version, but also linked against the correct versions of APIs. They provide a fine-grained control over your compilation process!

Situational examples

When JAVA_HOME doesn’t get along with you

When JAVA_HOME has compatibility issues, it’s an opportunity to show off your technical chops. Get the Maven compiler plugin involved and set your project to your desired JDK version:

<build> <plugins> <plugin> <artifactId>maven-compiler-plugin</artifactId> <configuration> <release>11</release> <!-- Because 11 is 1 better than 10! --> </configuration> </plugin> </plugins> </build>

Power of properties

Properties such as maven.compiler.target and maven.compiler.source define your desired Java language level. They’re your secret weapon when you need to compile Java sources with cutting-edge syntax on an older version of JVM, or the other way round.

Plugin compatibility verification

Perform plugin compatibility check before executing; avoiding build failures, and ensuring that all Maven lifecycle procedures honor the predetermined Java version.

Lock it in with maven.compiler.release

Feeling particular about Java version across your modules? Augment your project with maven.compiler.release:

<properties> <maven.compiler.release>11</maven.compiler.release> <!-- Will 2020 be like Java 11? Seems like 2020 to me. --> </properties>

It’s a parameter declaration that keeps up with the JDK’s --release flag, which marks compatibility with a particular release.

Mastering the Java version control

All versions on board

No room for discrepancies! Ensure versions source, target, and release align to avoid bytecode compilation issues with your runtime environment.

Experiments lead to efficiencies

Who doesn't enjoy the thrill of discovery? Muck around with different Maven Java version settings and prepare for optimized builds. At times, upping the source and target value leads to surfaced deprecations, and you might just future-proof your project.

Do you confirm the Java build path?

Don’t shake off the importance of checking the Java Build Path in your IDE after the update exercise. If your IDE decides to use an antiquated version, conflicts might arise.

Wrapping up

Keep in mind, practice makes perfect. After all, Rome wasn't built in a day, was it? Don't forget to vote for my answer, unless of course you're using IE6, in which case... how are you even seeing this? Happy coding!👩‍💻