toggle quoted messageShow quoted text
I agree with Mark, I don't believe that MR behaviour should necessarily apply to WAR and EAR files.
Sure if you give war file to a java9 ClassLoader, it will happily version WEB-INF/web.xml. However it is not a correct thing to do to give a war file to a java9 ClassLoader, as it will not be able to load any classes from WEB-INF/classes (versioned or not). So while a war is a jar, it is not a classloadable jar.
Also the precedent set by the java9 ClassLoader itself is that meta-data is not versioned - ie all of META-INF is excluded from versioning. It's thus reasonable to say that MR considerations should not automagically apply to WEB-INF either.
Furthermore, I see no reason for a war file to support MR in any way other than WEB-INF/lib may contain MR jars. Versioning other resources in a war makes no sense as any selection of resourced based on version surely should be the client version not the server version?
On 15 January 2018 at 13:17, Mark Thomas <markt@...>
On 09/01/18 15:18, bitonti@... wrote:
> Looking over the JEP238 and JavaDoc, the focus is on resource lookup. I
> don't see any behavior which distinguishes a class type resource from a
> non-class type resource. Once a resource is available in a JAR it never
> goes away. Once the resource of a member class is available at a MR
> version, it remains available at all higher MR versions.
> From a metadata perspective, I'm seeing mixed directions. Metadata
> which is provided beneath META-INF is fixed across all MR versions.
> But, module descriptors can be MR version specific. Module "uses"
> clauses can be MR version specific. Then, does that imply a need to
> handle different class paths for JavaEE modules -- which contradicts
> that META-INF metadata is fixed?
> From an annotation scanning perspective, the best I've determined is
> that some annotations will be independent of MR version (probably
> anything that can be mapped back to module descriptors, which live in
> META-INF, and which is MR version independent), while other annotations
> are tied to class details and will vary across MR versions (for example,
> @Trivial, which WebSphere uses for dynamic trace injection.) The
> question that I have is whether any JavaEE active annotations would be
> of the runtime type, meaning, allowed to vary by MR version.
> I presume that WAR and RAR files, as specializations of JAR files,
> automatically acquire the MR JAR behavior.
My starting position is the opposite.
The summary in JEP 238 starts:
"Extend the JAR file format to allow multiple, Java-release-specific
versions of class files to coexist in a single archive."
That says to me, multi-release features are intended only for classes.
Secondly, WAR files do not implement all the features of JARs. See the
glossary of the Servlet spec for some explicit examples.
Therefore, unless the behaviour is explicitly called out in the Servlet
spec my starting position is that a WAR file does not support it.
> For WAR files there seem to
> be questions about how exactly to map base resources to the MR version
> specific locations, e.g., should "WEB-INF/classes" be discarded. (A
> simplistic extension of MR JAR function to WAR files would not be aware
> of "WEB-INF" as a distinguished directory and would carry that into the
> mapped MR version specific locations.)
> Thomas Bitonti
> IBM - WebSphere Application Server