RFR: 8176508 Update JAX-WS RI integration to latest version

Alan Bateman Alan.Bateman at oracle.com
Sun Mar 12 15:14:15 UTC 2017



On 12/03/2017 14:39, Roman Grigoriadi wrote:
> Hi,
>
> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8176508
> Webrev: 
> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/00/
>
I skimmed the changes and have a few comments (I'm sure Lance or someone 
else will do a more detailed review).

In JAXBContext then "must be open to the java.xml.bind module" should be 
"must be open to at least the java.xml.bind module" so as to cover the 
case that the package is opened unconditionally or to java.xml.bind and 
other modules. In addition, include "at least" makes it consistent with 
other wording that we have agreed for other areas.

In MailcapCommandMap then the following doesn't seem right for the class 
description:

   59  * (Where <i>java.home</i> is the value of the "java.home" System 
property
   60  * and <i>conf</i> is the directory named "conf" if it exists,
   61  * otherwise the directory named "lib"; the "conf" directory was
   62  * introduced in JDK 1.9.)

It might be simpler to just have javadoc specify that it attepts to 
locate the `mailcap` file in the Java run-time image and then add an 
@implNote with the details as to where it looks for specific runtime 
releases.

I see the new source file ModuleUtil is using java.util.StringTokenizer. 
It's use in new code has been discouraged for many years and maybe this 
could start out using String.split rather than the legacy class.

The change to version.properties reminds me to ask if there is anything 
in the jaxws repo to indicate the version of the JAX-* components? It's 
often difficult to determine what bits are in the JDK vs. the upstream 
project.

-Alan


More information about the core-libs-dev mailing list