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