JDK-8132554 : Re-examine supportedness com.sun.tools.jxc and com.sun.tools.xjc APIs
  • Type: Enhancement
  • Component: xml
  • Sub-Component: jaxb
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2015-07-29
  • Updated: 2018-04-27
  • Resolved: 2018-04-27
Related Reports
Relates :  
JDK-8138586 - Provide a unified programmatic way to invoke JDK tools
Relates :  
JDK-8134326 - Invoking com.sun.tools.internal.jxc.SchemaGenerator through reflection with -XaddExports causes runtime error
Relates :  
JDK-8134153 - Re-examine supportedness com.sun.tools.internal.ws APIs
Description
Currently JDK jigsaw build makes inaccessible classes allowing to run schema generation tool and schema compilation tool from java; namely following classes:
- com.sun.tools.internal.jxc.SchemaGenerator
- com.sun.tools.internal.xjc.Driver

We believe they should be made accessible or other means to run these tools from java should be made accessible.
Comments
The Java EE modules have been removed from the JDK.
27-04-2018
Removing the label 'conformance'.
18-10-2016
One thing to mention is that exporting an API or implementing ToolProvider (JDK-8159855) will mean the jdk.xml.ws module will be resolved by default. We will need to reconcile the policy for root modules described in JEP 261.
31-07-2016
Note that -addmods is not a workaround. JEP 261 defines the default root module policy that EE modules and its tools have to be added to the root set explicitly. JCK test harness depends on the JDK internal API and hence it has to break the encapsulation via command-line option. This issue is an enhancement request. It's not a bug.
14-06-2016
[~mchung], relying on this workaround is giving a lot of surprises. For example, this issue JCK-7306321 shows how frequent/unforeseen changes in -addmods and -XaddExports workarounds has caused the precompile failures and on every failure a lot of bandwidth has to be spent for analysis and fix. It would be really great if this ticket can be fixed ASAP.
14-06-2016
Fix Version of 9 had mistakenly been set by JCK team. This field has been cleared.
14-06-2016
Removing Fix version to avoid any possible confusion.
14-06-2016
Shihua will have to comment on the due date for this issue as this issue can be solved by providing an exported API from jdk.xml.bind module. JDK-8138586 is target of opportunity. When JDK-8138586 is resolved, this issue could be resolved using that service interface which is another solution to this issue. [~pchinnasamy] any issue with using -XaddExports in JDK 9?
09-06-2016
Mandy and Shihua, can you think of any due date for this issue? Or -addmods -XaddExports for the relevant modules are going to stay forever?
08-06-2016
About 1200+ new failures related to javax_xml seen with JCK-runtime9/b36 (Group jvm mode) on JDK9b118, JDK9b119 & JDK9b120, but after JDK9b116. http://aurora.ru.oracle.com/functional/faces/RunDetails.xhtml?names=1461653.ute.st2-4-20160520092250167-20160524035235984 Most of the failures passed with the workaround "-addmods jdk.xml.ws,jdk.xml.bind " for example, /export/home/gtee/jdk-9-120/bin/java -addmods jdk.xml.ws,jdk.xml.bind -Xshare:auto -showversion -XX:+TraceClassPaths -Xfuture -classpath /net/stt-13.ru.oracle.com/export/home0/stt/jck_promotions/9/latest/binaries/JCK-runtime-9/lib/javatest.jar:/net/stt-13.ru.oracle.com/export/home0/stt/jck_promotions/9/latest/binaries/JCK-runtime-9/lib/jtjck.jar:/net/stt-13.ru.oracle.com/export/home0/stt/jck_promotions/9/latest/binaries/JCK-runtime-9/lib/extensions/JCK-extensions.jar:/net/stt-13.ru.oracle.com/export/home0/stt/jck_promotions/9/latest/binaries/JCK-runtime-9/lib/extensions/JCK-extensions.jar -Djava.security.policy=/net/stt-13.ru.oracle.com/export/home0/stt/jck_promotions/9/latest/binaries/JCK-runtime-9/lib/jck.policy -Djava.rmi.activation.port=57902 com.sun.jck.lib.ExecJCKTestSameJVMCmd -loadDir /net/stt-13.ru.oracle.com/export/home0/stt/jck_promotions/9/latest/binaries/JCK-runtime-9/classes -loadImpl /net/stt-13.ru.oracle.com/export/home0/stt/jck_promotions/9/latest/binaries/JCK-runtime-9/lib/extensions/JCK-extensions.jar javasoft.sqe.tests.bind.jaxbcontext.JAXBContext_CTTests -TestURL file:/net/stt-13.ru.oracle.com/export/home0/stt/jck_promotions/9/latest/binaries/JCK-runtime-9/tests/api/javax_xml/bind/JAXBContext/JAXBContext_.html#JAXBContext_CTTests -package javasoft.sqe.tests.bind.jaxbcontext -schema JAXBContext.xsd JAXBContext.xsd [0.000s][warning][arguments] -XX:+TraceClassPaths is deprecated. Will use -Xlog:class+path=info instead. [0.004s][info][class,path] bootstrap loader class path=/export/home/gtee/jdk-9-120/lib/modules [0.004s][info][class,path] classpath: /net/stt-13.ru.oracle.com/export/home0/stt/jck_promotions/9/latest/binaries/JCK-runtime-9/lib/javatest.jar:/net/stt-13.ru.oracle.com/export/home0/stt/jck_promotions/9/latest/binaries/JCK-runtime-9/lib/jtjck.jar:/net/stt-13.ru.oracle.com/export/home0/stt/jck_promotions/9/latest/binaries/JCK-runtime-9/lib/extensions/JCK-extensions.jar:/net/stt-13.ru.oracle.com/export/home0/stt/jck_promotions/9/latest/binaries/JCK-runtime-9/lib/extensions/JCK-extensions.jar [0.004s][info][class,path] opened: /export/home/gtee/jdk-9-120/lib/modules java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+120) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+120, mixed mode) createBinder001: Passed. OK createMarshaller001: Passed. OK createUnmarshaller001: Passed. OKAY createBinder002: Passed. OK createJAXBIntrospector001: Passed. Ok testModuleFinder = null testModuleName = null rootModules = [] locations = [file:/net/stt-13.ru.oracle.com/export/home0/stt/jck_promotions/9/latest/binaries/JCK-runtime-9/classes/, file:/net/stt-13.ru.oracle.com/export/home0/stt/jck_promotions/9/latest/binaries/JCK-runtime-9/lib/extensions/JCK-extensions.jar] chosen loader = java.net.URLClassLoader@7c29daf3 chosen loader's parent = jdk.internal.loader.ClassLoaders$AppClassLoader@591f989e executeArgs = [-TestURL, file:/net/stt-13.ru.oracle.com/export/home0/stt/jck_promotions/9/latest/binaries/JCK-runtime-9/tests/api/javax_xml/bind/JAXBContext/JAXBContext_.html#JAXBContext_CTTests, -package, javasoft.sqe.tests.bind.jaxbcontext, -schema, JAXBContext.xsd, JAXBContext.xsd] java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+120) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+120, mixed mode) STATUS:Passed.test cases: 5; all passed
27-05-2016
-addmods java.se.ee only includes Java EE modules but not jdk.xml.bind nor jdk.xml.ws. If you run jigsaw/jake, -XaddExports in jake only supports the new syntax as described in JEP 261. Try this: -addmods jdk.xml.ws,jdk.xml.bind \ -XaddExports:jdk.xml.bind/com.sun.tools.internal.xjc=ALL-UNNAMED \ -XaddExports:jdk.xml.bind/com.sun.tools.internal.jxc=ALL-UNNAMED \ -XaddExports:jdk.xml.ws/com.sun.tools.internal.ws=ALL-UNNAMED -
26-04-2016
The options "-addmods java.se.ee -XaddExports:jdk.xml.bind/com.sun.tools.internal.xjc=ALL-UNNAMED,jdk.xml.bind/com.sun.tools.internal.jxc=ALL-UNNAMED,jdk.xml.ws/com.sun.tools.internal.ws=ALL-UNNAMED " is throwing the following exception now: Error occurred during initialization of VM java.lang.RuntimeException: Unknown module: jdk.xml.bind at jdk.internal.module.ModuleBootstrap.fail(java.base@9-ea/ModuleBootstrap.java:526) at jdk.internal.module.ModuleBootstrap.addExtraExports(java.base@9-ea/ModuleBootstrap.java:447) at jdk.internal.module.ModuleBootstrap.boot(java.base@9-ea/ModuleBootstrap.java:308) at java.lang.System.initPhase2(java.base@9-ea/System.java:1917) And looking at https://java.se.oracle.com/source/xref/jdk9-dev/jaxws/src/jdk.xml.bind/share/classes/module-info.java, com.sun.tools.internal.xjc or com.sun.tools.xjc are not getting exported.
25-04-2016
JDK-8138586 proposes to have tools to be providers of javax.tools.Tool. It is not a generic solution to all JDK tools. javax.tools is in java.compiler module and a tool that provides the Tool service interface will require java.compiler but not all tool modules require java.compiler. keytool is in java.base that can't have any dependence. I still like javax.tool.ToolProvider to define a method to look up any tool programmatically but this may require a new service type to be defined in java.base.
16-02-2016
Wouldn't be nice for tools to support javax.tools.Tool interfaces (JSR-199)?
16-02-2016
One option is to define the main class of these tools in an exported API package. For example: jdk.xml.ws.WsGen jdk.xml.ws.WsImport jdk.xml.bind.jxc.SchemaGenerator jdk.xml.bind.xjc.Driver WsGen and WsImport are currently in the same package. For the other tools, it could be named Main.java. Some JDK tools such as javac defines two methods: public static void main(String��� args); public static int run(String[] args, PrintWriter out); JAX-WS and JAXB tools can follow this convention. CCC will need to be filed to propose these new classes are exported external interfaces.
16-02-2016
A workaround for jck4jdk: -vmoptions:'-XaddExports:jdk.xml.bind/com.sun.tools.internal.xjc=ALL-UNNAMED,jdk.xml.bind/com.sun.tools.internal.jxc=ALL-UNNAMED,jdk.xml.ws/com.sun.tools.internal.ws=ALL-UNNAMED'
11-02-2016
Perhaps we should consider providing a supported main class to launch the tools e.g. jdk.xml.ws.jxc.Main in JDK 9. That would be the simplest solution.
28-01-2016
In some circumstances invoking com.sun.tools.internal.jxc through reflection with -XaddExports option specified causes run time error, please see this issue for details: JDK-8134326.
24-08-2015
Similar issue related to jax-ws is filed: JDK-8134153
21-08-2015
com.sun.tools.internal.jxc and com.sun.tools.internal.xjc are not supported APIs and hence they are not exported. Is JCK-devtools-9 dependent on the tool as for the test setup and doesn't want to invoke xjc and jxc tool? Not the JCK tests themselves depending on this internal API? com.sun.tools.jxc and com.sun.tools.xjc are repackaged in JDK 9 to com.sun.tools.internal.jxc and com.sun.tools.internal.xjc and clearly stated that is internal. We should re-examine the supportedness of com.sun.tools.jxc and com.sun.tools.xjc packages; if supported, a CCC should be filed to track that and not repackage them.
13-08-2015
JAXB RI should also make analogous API accessible to end user, namely following classes: com.sun.tools.jxc.SchemaGenerator com.sun.tools.xjc.Driver
29-07-2015