JDK-8158954 : Update JAX-WS and JAXB to use new Catalog API on JDK 9
  • Type: Enhancement
  • Component: xml
  • Affected Version: 9
  • Priority: P2
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2016-06-07
  • Updated: 2017-01-30
  • Resolved: 2016-10-13
Related Reports
Relates :  
JDK-8164479 - Update JAX-WS RI integration to latest version (2.3.0-SNAPSHOT)
Description
com.sun.org.apache.xml.internal.resolver.Catalog and the related classes have been replaced with a new set of API's in JDK 9
javax/xml/catalog.
However, there is no simple solution for projects that need to support JDK 8 and JDK 9.
The com.sun package should remain visible for JDK 9.
Comments
The changes for this have been rolled into the sync of JAXB + JAX-WS that is JDK-8164479.
13-10-2016
Aleksej - can you tell if Stephen is using the right build? The static dependences on com.sun.org.apache.xml.internal.resolver.tools.* are, I assume, the code that is used when on JDK 8 and older. On JDK 9 then it should be using the XML catalog API and so IllegalAccessError should not be thrown - is it possible that the version detection isn't working or that the wrong build is being used?
17-09-2016
Aleksej has kindly agreed, together with me, to work on this issue. We will update the JAX-WS/JAXB code so that it works for both JDK 9 and earlier releases.
17-06-2016
I've changed the synopsis on the bug to reflect what this issue now tracks.
17-06-2016
com.sun.org.apache.xml.internal.resolver.* has always been JDK-internal. It has not been removed in JDK 9 but is no longer accessible by default (need to use -XaddExports to break encapsulation). Having it exported unconditionally by java.xml is not an option for both design principles and conformance reasons. Moving it to jdk.unsupported is also problematic - even if feasible then we fall foul of the issue that a standard module would depend on a JDK-specific module. Solutions to explore here are multi-release JARs or making use of the new API via core reflection.
08-06-2016
In general, I think that API's should not be removed in the same release as replacement API's are provided. If they are important enough to replace, then applications must be using them and it's difficult to migrate in a single release.
08-06-2016