How do I support an application built using Java 1.8 in Java 9?

Question

We have a standalone application built using Java 1.8 and when I test running that application using Java 9, I get a NoClassDefError exception on the javax.xml.soap.SoapException class. I have read enough to know that Java 9 now has the module concept... and that if I add the "--add-modules java.se.ee" option on my 'java' call in the startup script for the application, it then runs correctly.

My question is... how do I still support this application running against a 1.8 JRE? I can't just put the --add-modules option in the startup script since that causes an error when attempting to run against the 1.8 JRE. I really don't want to have to put logic in the startup script to try to determine which version of JRE the user is running and optionally put the new --add-modules option in there.

Any suggestions? Thanks in advance!

Answer 1

You should include java9 specific information 'module-info.java' into your application, so it will not require the command line option. See e.g. here: How to add a Java 9 module via manifest.mf?

Answer 2

The web services module (java.xml.ws, which includes SAAJ) has been deprecated in Java SE 9 with a view to removing it from Java SE and the JDK in the future. The first step on that road to removing it is to not resolve it by default. It is "as if" the module does not exist and this is why you get a CNFE when you run it on JDK 9.

Yes, you can workaround around it temporarily with --add-modules=java.xml.ws (more precise than --add-modules=java.se.ee) and you should be able to get your script to pick this up using the JDK_JAVA_OPTIONS env variable (see http://jdk.java.net/9/release-notes#JDK-8170832) which is new in JDK 9 and so will be ignored in JDK 8.

The alternatives (and the JDK 9 Migration Guide will have more on this) is to move to the standalone version of JAX-WS and SAAJ. These APIs have standalone versions that update at a different pace to Java SE and the JDK. You should find the latest (2.3.0) in Maven for example. The standard versions can be deployed on the class path, and in the future as modules in the event that you migrate your application to modules in the future.