JDK-8047775 : Audit JAX-WS and SAAJ, scope out API/other changes that might be needed to work with modules
  • Type: Task
  • Component: xml
  • Sub-Component: jax-ws
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-06-22
  • Updated: 2016-01-06
  • Resolved: 2015-06-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Fixed
Related Reports
Relates :  
JDK-8129960 - JAX-WS tools - exporting generated java types
Relates :  
JDK-8047773 - Remove JAF's API dependency on java.beans.Beans.instantiate
Relates :  
JDK-8049379 - Examine reference to ${java.home}/lib in javax.activation.MailcapCommandMap
Relates :  
JDK-8080502 - Update JAXB and JAX-WS to work with resource encapsulation
Relates :  
JDK-8049381 - Examine references to ${java.home}/lib in javax.xml.soap
Relates :  
JDK-8061466 - RELAX NG API visible but not accessible
Relates :  
JDK-8051407 - Re-examine dependency from JAX-WS to java.rmi.Remote and RemoteException
Relates :  
JDK-8049380 - Examine reference to ${java.home}/lib in javax.xml.ws.spi.Provider
Description
This task is submitted to track auditing of JAX-WS and SAAJ with a view to scoping out what API and other changes (if any) are required for these APIs to work with modules in Java SE 9 / JDK 9. It is important to understand if API changes will be required as both APIs are tied to standalone JSR (JSR-224 and JSR-67) and so might require JCP activity to update.
Comments
Linked identified issues. Out of these, there will be most probably some more accessibility problems to be solved by Module::addReads
26-06-2015
Miran - would it be possible to write in an updated status? It may be that we can close this issue and create issues for follow-on updates (like the MR for the JSR and any javadoc updates that are needed).
25-06-2015
Overall status. To have complete picture, all the unit tests must be transformed not to use any tools and use named modules. JAX-WS tests already transformed, some of those also run in named module. Currently known issues: 1) using service loader - CCC 8072839 (JAX-B) in process - in JAX-B and SAAJ java.util.ServiceLoader can't be used without introducing new interface/class and changing the name being looked for 2) property file configuration in implementation discovery algorithms - applies for SAAJ( JDK-8049380, JDK-8049381, JDK-8049380) 3) requirement to export java types (generated, but not only) from client module because of using reflection on those - applies to JAX-WS - after transforming unit tests we'll have more complete picture what must be exported 4) changing jax-ws tools to generate with java types also necessary exports for module-info.java / or complete module-info.java (?) - not sure if we need it - user could do it by himself, but it is "nice to have".
13-03-2015
yes, due to service discovery, there are at least minor changes necessary in JAXB, same situation would be definitely in SAAJ and maybe in JAX-WS. I am working on further testing to see if I discover something more.
18-11-2014
The Oracle internal wiki has links to material and prototype builds that should be useful to get started on this task. The main thing that needs to identified areas where JAX-WS or SSAJ is specified or is assuming that public types are accessible. These, plus uses of Core Reflection, are likely to be the areas that might need attention in order to work with module boundaries.
22-06-2014