Which maven for java 11?

The first thing you should do before even thinking about upgrading the Java version is to clean up your pom.xml files. If your project is a multi-module Maven project then it helps to establish a parent POM and maintain dependencyManagement und pluginManagement in this file. That way all your plugins and dependencies are defined in a single file and are not spread across multiple POM files what makes managing versions easier.

In order to migrate your project to the latest Java version 11 it’s highly recommended to update as much plugins and dependencies to the latest stable version as possible. Many plugins such as the compiler plugin, surefire or failsafe are not compatible with Java 9 if you use older versions. Also a lot of libraries are incompatible without migrating to the latest version.

Make sure you have the versions plugin configured in your master POM:

This plugin helps finding the latest plugin or dependency versions for your modules. Open up the terminal and execute this command to find the plugin versions you have to update:

You will see a list of plugins used in your project with newer versions available. Update all of those plugins to the lastest stable version. After you’ve updated your plugin versions make sure that your project still compiles and runs properly.

The most important plugins for Java 11 are the compiler plugin, surefire (for unit-tests) and failsafe (for integration-tests).

In order to compile your project for Java 11 add the release configuration to the compiler plugin, a new compiler parameter to replace the source and target version parameters:

For surefire and failsafe plugins we add an additional argument --illegal-access=permit to allow all reflection access for third party libraries:

This is only needed if your dependencies make heavy use of reflection. If you’re unsure whether you need this you can add the argLine later if your tests run into trouble.

You’ll see warnings like this when a library tries to illegally access classes via setAccessible(true):

As mentioned before the best thing you can do is to migrate all your dependencies to the latest stable versions to make sure everything works fine with Java 11. While many older dependencies might work just fine there’s a couple of dependencies where version updates are mandatory, e.g. all those various bytecode enhancement libaries such as javassist, cglib, asm or byte-buddy. Those libraries often come as transitive dependencies so make sure at least those libaries are up-to-date.

This command helps to find outdated dependency versions from your modules:

Update as much libaries as possible to the latest stable version. If there’s some dependency that you can’t update due to compatibility issues in your project than leave it as is. Chances are that it just runs fine with Java 11.

Now is a good time to compile your project with JDK 11 for the first time:

You will eventually face different compiler errors such as ClassNotFoundException. Every project is different so I cannot provide solutions for every problem you will face. The rest of this article describes solutions to various problems we had to solve in order to run our application with JDK 11.

With the introduction of the Java module system (Jigsaw) in Java 9 the Java standard libary has been divided into separate modules. While most classes are still available without any changes, some are not. You have to explicitely define which additional modules your application needs access to or you can just add those modules from the Maven central repository.

When migrating our web project to Java 11 we had to add jaxb and javax.annotations to prevent ClassNotFoundException. We’ve added the following libaries as additional Maven dependencies to our POMs:

While some classes have been moved to additional Java modules other classes can no longer been used in user code, namely classes from sun.* packages and also some classes from com.sun.*. If you get compiler errors because your code links to classes from those packages you have to remove those imports from your code.

Here’s a few things we had to fix in our project:

We’ve encountered a curious case with number formats for locales such as Locale.GERMANY which let a bunch of our tests fail with a rather strange assertion error:

The underlying code uses NumberFormat.getCurrencyInstance(Locale.GERMANY) to format numbers into the german currency format. So what the heck is happening here?

Javas number formats have been modified to use non-breaking spaces instead of normal spaces between the number and the currency symbol. This change makes perfectly sense because it prevents line-breaks between the number and the currency symbol in various presentation formats. Changing the strings in our tests to use non-breaking spaces (use OPTION SPACE on Mac OSX keyboards) fixed this issue.

When running web applications with Apache Tomcat you need at least Apache Tomcat 7.0.85 or later. Otherwise Tomcat will not start on Java 9 and above and you would see the following error:

• Download maven zip file from Maven Download and extract the zip file.
• Keep the folder in Program Files at : C:\Program Files\apache-maven-3.8.6-bin.
• MAVEN_HOME.
• Maven Path.

Check Maven Java Version

Since Maven is also runnig with Java, check first with which version your Maven is running on:

It returns:

Incompatible version

Here above my maven is running with Java Version 1.8.0_151. So even if I specify maven to compile with Java 11:

It will logically print out this error:

How to set specific java version to Maven

The logical thing to do is to set a higher Java Version to Maven (e.g. Java version 11 instead 1.8).

Maven make use of the environment variable JAVA_HOME to find the Java Version to run. So change this variable to the JDK you want to compile against (e.g. OpenJDK 11).

Sanity check

Then run again mvn --version to make sure the configuration has been taken care of: