To address the first point only... I think if Java EE 8 required Java SE
9, that would be surprising news for all. For the last few Java EE
releases at least, each Java EE release has required the Java SE version
of the same number. And there has been plenty of talk over the past
couple years that seems to indicate that this will continue to 9. Thus
I have no expectation that Java EE 8 will do anything special for Java SE 9.
However, we definitely want our implementation to run on Java SE 9. My
understanding was that you cannot replace classes in upgradeable modules
via the class path, but if that's wrong then I suppose it's time to do
another round of experiments.
On 04/20/2017 11:45 AM, Stephen Felts wrote:
First, I'm not sure that Java EE 8 (corresponding to Java SE 9) will define
modules.
It seems that the RI will tolerate JDK9 (remove internal JDK API calls) as
opposed to adopting the new module system.
Since javax.annotation.* classes are now hidden in JDK 9, every project that
uses these classes will need to ship a copy of these classes.
For a project that is not adopting the module system, these classes will be on
the classpath. They can just ship the RI jar file (currently
glassfish4/glassfish/modules/endorsed/javax.annotation-api.jar) and in JDK9
endorsed is no longer supported but no longer needed for these classes (that's
the reason for hiding the classes).
To provide the jax-ws annotations (they seem to live in
glassfish4/glassfish/modules/endorsed/webservices-api-osgi.jar) also on the
classpath, it just works.
Both jar files need to be provided by project that uses these annotations and
added to the classpath directly or indirectly via a manifest classpath.
(As a side note, there are some API's that are not in the endorsed directory
that will need to be additionally shipped for projects that use them.)
For a project that is adopting the module system, the jar files need to be
turned into modules with the correct names and the associated module-info.class
in the root.
Both modules need to be shipped and both jar files need to be in the module
path or upgrade module path?
If two projects run in the same JVM, one using the classpath and one using the
module path, the module path wins?
-----Original Message-----
From: David M. Lloyd [mailto:david.ll...@redhat.com]
Sent: Thursday, April 20, 2017 9:21 AM
To: Alan Bateman; jigsaw-dev
Subject: Re: How to actually ship JSR-250?
On 04/20/2017 08:18 AM, Alan Bateman wrote:
On 20/04/2017 13:57, David M. Lloyd wrote:
Let's say I want to create a module distribution with my own JSR 250
classes. Let's also assume that I or the spec team want the module
to be named java.annotations.common.
How do I properly upgrade the JDK's java.xml.ws.annotation module
such that java.xml.ws can see it, *and* I have my proper
java.annotations.common module name? Am I forced to ship my
annotations module as java.xml.ws.annotation? Or manually replace
java.xml.ws with one that looks for my annotations (and where does
that leave the original java.xml.ws.annotation module)?
java.xml.ws.annotation is upgradable so all you need to do is deploy
the compiled form of the following on the upgrade module path:
module java.xml.ws.annotation {
requires transitive java.annotations.common; }
Separately, I don't know what name that JSR-250 will eventually choose.
It could be indeed be "java.annotations.common", maybe
"java.ee.annotation", maybe something else.
I'm not too worried about that; it has to be decided by the time of Java EE 9
(obviously) but until then I just want to ensure that it is definitely possible
to do this, as (unless I missed something) I don't believe that it was
adequately covered in prior discussions.
--
- DML
--
- DML
