AW: Java 9 EA 169 Webstart NoClassDefFoundError: javax/xml/ws/Service

Andrew Guibert aguibert at
Fri May 19 15:28:43 UTC 2017

Hi all,

According to JEP 261 the specific modules are being excluded for
the sake of app servers since we already typically override them. As a
developer of a Java EE app server, while this gesture is appreciated, I
think it does more harm than good to the wider Java community because many
Java programs that are unrelated to Java EE app servers depended on these
APIs in Java 8 and do not override the JDK set with their own versions.

Excluding `` specific modules from the root set by default seems
to border on violating the "deprecated for at least one release before
removal" rule of Java.  There was no indication in Java SE 8 [1] that these
classes would be removed in Java SE 9.  Technically they are not "removed
from the JDK"... hey are still there if you add them with the command line
arg, but they are not there by default and I think that's the part that
matters.  Giving framework owners all of JDK 9 as a runway to update their
apps to use their own versions of `` modules would be extremely

In my experience in adopting Java 9 and helping others to run on Java 9,
the missing "" modules has been the most common "gotcha" of JDK 9
(now that illegal access is permitted by default).

Confusingly, the default set of root modules is defined as [2]:
 - The module is a root, if it exists. If it does not exist then
every java.* module on the upgrade module path or among the system modules
that exports at least one package, without qualification, is a root.
 - Every non-java.* module on the upgrade module path or among the system
modules that exports at least one package, without qualification, is also a

Which is a long way of saying "everything but modules are a

Here is a quick list of references I could find to people being confused by
the default root module set not including all modules by default:
<this thread>

As a resolution, could we make all observable modules root modules by
default?  This would greatly simplify the definition of a root module to
 - Every system module or module on the upgrade module path that exports at
least one package is a root.

In my eyes, the two critical migration issues with JDK 9 are:
 1) Encapsulation of JDK apis
 2) Not including the "Java EE APIs" in the default set of root modules for
the unnamed module

(1) has been resolved by making `--illegal-access=permit` default
(2) could be resolved with this proposal, or mitigated by having an
`Add-Modules` manifest header

[1] javadoc:
[2]: JEP 261 root module definition:

- Andy

> From: Michael Rasmussen <michael.rasmussen at>
> To: Reto Merz <reto.merz at>
> Cc: jigsaw-dev <jigsaw-dev at>
> Date: 05/17/2017 03:13 AM
> Subject: Re: AW: Java 9 EA 169 Webstart NoClassDefFoundError: javax/
> xml/ws/Service
> Sent by: "jigsaw-dev" <jigsaw-dev-bounces at>
> On 16 May 2017 at 16:52, Reto Merz <reto.merz at> wrote:
> > They need weeks to plan and test an upcoming server-side
> > software update before they can install it on the production system.
> > Java 9 will be released on 2017/07/27, so we are under high
> business pressur.
> Assuming Java 9 follows a similar path at Java 8, it will be around 6
> months after release, before Java 9 is the default download on
>, and another 6 months before the auto-updater will update JRE
> installations from java 8 to java 9.
> Yes, for those users who actively seek out java 9 on day one, there
> can be issues, but for the average consumer, there is a 6-12 month
> period from release before Java 9 will be on their computers.
> Yes, we still have to go through all the work of migrating to Java 9,
> but should the above hold true for Java 9, we do at least have a bit
> of breathing room, before it is actively being pushed to users.
> /Michael

More information about the jigsaw-dev mailing list