Re: 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


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.rasmus...@zeroturnaround.com>
> To: Reto Merz <reto.m...@abacus.ch>
> Cc: jigsaw-dev <jigsaw-dev@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-boun...@openjdk.java.net>
>
> On 16 May 2017 at 16:52, Reto Merz <reto.m...@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
>

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

[Michael Rasmussen]

On 16 May 2017 at 16:52, Reto Merz  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

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

[Alan Bateman]

On 16/05/2017 12:26, Reto Merz wrote:


So I think Java Web Start is right to align with the policy for
applications launched on the command line.

The difference is that in case of Webstart the Java version is controlled by 
the user.
They are trained to install the latest Java version and keep it up-to-date.
All our customers download Java via java.com
They would not understand that they should stay with an old Java version until 
release X of software Y is available because they have never do that before.
We use Webstart over 10 years and it is the first time we see that Oracle will 
break compatibility between Java N and N+1 and Oracle is already aware about it.
The issue is easy to fix because only the Webstart launcher would be affected 
by the changes.
This changes would give Webstart app devs more time to migrate.

I think it is wrong to compare Webstart with a classic application
and Oracle should add all SE/EE modules by default and also enable 
--permit-illegal-access
by default in case ob Webstart.

The JNLP fragment in my first mail can be used to resolve java.xml.ws 
for JNLP applications that depend on the JAX-WS version included in the 
JRE. It's predicated on the version of the runtime so you should be able 
to use the same JNLP for 6, 7, 8 and 9.


I don't know when JDK 10 will be released and I also don't know for sure 
if JRE 10 will continue to bundle JAX-WS or not. Assuming it is removed 
then it will be a surprise as the JDK has never dropped APIs like this. 
I don't think we should feel too bad about that because each of these 
APIs are standalone technologies with their own download. BTW: We don't 
maintain these APIs in OpenJDK, instead they are maintained in upstream 
projects. I could imagine the migration guide for JDK 10 providing the 
JNLP need to download the standalone versions as libraries.


As regards strong encapsulation then Java Web Start has support for the 
equivalent of `--add-exports` and `--add-opens`. I think we discussed 
this in a previous thread (you mentioned you inherited code that hacks 
String internals if I remember correctly).


-Alan.