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

[Andrew Guibert]

Hi all,

According to JEP 261 the java.se.ee 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 `java.se.ee` 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 `java.se.ee` modules would be extremely
helpful.

In my experience in adopting Java 9 and helping others to run on Java 9,
the missing "java.se.ee" 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 java.se 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
root.

Which is a long way of saying "everything but java.se.ee modules are a
root".

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:
http://stackoverflow.com/questions/43574426/how-to-resolve-java-lang-noclassdeffounderror-javax-xml-bind-jaxbexception-in-j
http://stackoverflow.com/questions/42966880/java-lang-noclassdeffounderror-javax-xml-bind-datatypeconverter
http://stackoverflow.com/questions/42907605/how-do-i-include-a-java-9-module-at-runtime
http://stackoverflow.com/questions/40530898/gradle-does-not-honor-add-modules-jvm-argument-in-jdk9
http://stackoverflow.com/questions/43606502/how-to-add-a-java-9-module-via-manifest-mf
http://stackoverflow.com/questions/44051223/which-system-modules-are-on-the-module-path-by-default
http://stackoverflow.com/questions/43937401/error-while-running-allure-command-line-generate-command
https://bugs.eclipse.org/bugs/show_bug.cgi?id=493761
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012136.html
<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
be:
 - 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] java.sml.ws.Service javadoc:
https://docs.oracle.com/javase/8/docs/api/javax/xml/ws/Service.html
[2]: JEP 261 root module definition:
http://openjdk.java.net/jeps/261

- Andy

> From: Michael Rasmussen <michael.rasmussen at zeroturnaround.com>
> To: Reto Merz <reto.merz at abacus.ch>
> Cc: jigsaw-dev <jigsaw-dev at openjdk.java.net>
> 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 openjdk.java.net>
>
> On 16 May 2017 at 16:52, Reto Merz <reto.merz at abacus.ch> 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
> java.com, 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
>