8

I believe this problem not to be related to module exclusions in JDK 9 (as with java.se.ee), but rather with the fact that JDK 9 includes a newer version of org.w3c.dom.ls in the java.xml module that does not have the DocumentLS class.

The important bit of the stack trace is this:

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 a runtime dependency with this class, like xerces:xerces 2.4.0, the JDK java.xml module is preferred (I guess).

I am using Gradle 4.1. Is there any way to restrict the scope of a JDK provided module?

Christopher Johnson
  • 302
  • 4
  • 12

2 Answers2

4

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

Patch java.xml

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

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

I've never tried that with a JAR that contains some of the same classes. As I understand it, the JDK classes will then be replaced with the Xerxes classes, which means they better be a fully binary compatible replacement.

Upgrade java.xml

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

The upgrade module path (--upgrade-module-path) contains compiled definitions of modules intended to be used in place of upgradeable modules built-in to the environment (compile time and run time).

You face two problems:

  • the upgrade module path is supposed to be used only for upgradable modules (which java.xml is not), but I think I've read somewhere that that's not enforced (yet?) - didn't try it
  • the artifact you replace java.xml with needs to be fully binary compatible update - would that be the case for Xerxes?
Nicolai Parlog
  • 47,972
  • 24
  • 125
  • 255
  • Thanks for the insight and documentation references. I have now noticed that the class missing failure appears on runtime and not at compile time. Why does not the compiler not report "split package" issues at compile time? I guess that this DocumentLS class is a transitive runtime dependency of spring-core. I would rather opt to address the problem downstream as hacking the JDK, while interesting, is probably not portable. – Christopher Johnson Aug 18 '17 at 08:30
  • Also, I have tried to get more info about how the launcher resolves the split package with the -Xdiag:resolver option, but IntelliJ does not allow me to pass it as a Gradle VM runtime option... – Christopher Johnson Aug 18 '17 at 08:42
3

From what I can tell, DocumentLS is from a 2002 draft of the W3C API, it doesn't appear to have made it into a released version. It looks like xerces-2.4.0 (from 2006?) includes it but newer versions don't. So upgrading to a more recent Xerces may be needed here. If Spring really depends on DocumentLS then it will need to be updated too.

Alan Bateman
  • 5,283
  • 1
  • 20
  • 25