How to actually ship JSR-250?

[David M. Lloyd]

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.lloyd at 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