JDK 9: JUnit 5 test compiler with SpringExtension produces java.lang.NoClassDefFoundError: org / w3c / dom / ls / DocumentLS

Question

I believe this problem is not related to module exceptions in JDK 9 (as well as to java.se.ee), but rather because JDK 9 includes a newer version of org.w3c.dom.ls in the java.xml module, which does not have a DocumentLS class.

An important bit of the stack trace is the following:

Caused by: org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from class path resource [spring-test/test-container.xml]; nested exception is java.lang.NoClassDefFoundError: org/w3c/dom/ls/DocumentLS at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:414) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:336) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:304) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:181) 

Even if I include runtime dependency on this class, for example xerces:xerces 2.4.0 , the JDK module java.xml is preferred (I think).

I am using Gradle 4.1. Is there any way to limit the amount of JDK provided by the module?

Answer 1

As you correctly analyzed, the org.w3c.dom.ls package is present in the platform module java.xml . Any class in the class path that is in the same package will be ignored. This is called a split package and several fixes exist - the following two may help you.

Patch java.xml

You can add Xerxes JAR classes to the java.xml module with --patch-module :

 java --patch-module java.xml=xerxes-4.0.0.jar ... 

I have never tried this with a JAR that contains some of the same classes. As I understand it, the JDK classes will then be replaced by the Xerxes classes, which means that they are better compatible with full binary compatibility.

Java.xml update

Another hope is to replace java.xml with the path to the update module :

The path of the upgrade module ( --upgrade-module-path ) contains compiled definitions of modules intended to be used instead of updatable modules built into the environment (compilation time and run time).

You have two problems:

• the path of the updater should be used only for updatable modules (java.xml doesn’t), but I think I read somewhere that this is not forced (yet?) - have not tried it
• The artifact that you are replacing java.xml must be fully compatible with binary updating - will it be so for Xerxes?

Answer 2

From what I can say, DocumentLS from the 2002 W3C API project does not seem to have hit the released version. It seems that xerces-2.4.0 (since 2006) includes it, but newer versions do not. Therefore, it may be necessary to upgrade to later Xerces. If Spring really depends on DocumentLS, then it should also be updated.