Yes, you are correct that Java EE 8 won't require Java SE 9. This will be the first time that two versions of Java SE ship before the next Java EE.
There are a bunch of JDK 9 bugs against the RI but they are generally for internal API's. However, the RI won't be able to run on JDK9 until the API class problem is resolved, even if for the short term. Some of the classes are in the endorsed directory and some of the classes don't exist in the RI (e.g., javax.activation). The quick fix is to require the JDK9 option to make the EE classes in the SE visible. -----Original Message----- From: David M. Lloyd [mailto:david.ll...@redhat.com] Sent: Thursday, April 20, 2017 6:49 PM To: Stephen Felts; Alan Bateman; jigsaw-dev Subject: Re: How to actually ship JSR-250? 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
