RFR - 8132734: java.util.jar.* changes to support multi-release jar files

[Xueming Shen]

Steve,

   78  * <p>Class loaders that utilize {@code JarFile} to load classes from the
   79  * contents of {@code JarFile} entries should construct the {@code JarFile}
   80  * by invoking the {@link JarFile#JarFile(File, boolean, int, Release)}
   81  * constructor with the value {@code Release.RUNTIME} assigned to the last
   82  * argument.  This assures that classes compatible with the major
   83  * version of the running JVM are loaded from multi-release jar files.

What should be the expected result in scenario that the "multi-release" jar
file actually puts all latest version entries in the base and early version entries
in the "versions/n" directory? For example, in jdk 10, someone generates
a mr-jar file with all classes for jdk 10 at root, but a set of jdk9 implementation/
version entries under "versions/9" (assume we don't have class major version
compatible issue, both compiled with early version of javac). Those jdk9 version
classes will always get picked, even open with "Relese.VERSION_10"?


   59  * "META-INF/versions" directory.  The versioned entries are partitioned by the
   60  * major version of Java platform releases, starting with release 9.  A
   61  * versioned entry, with a version {@code n}, {@code 8 < n}, in the
   62  * "META-INF/versions/{n}" directory overrides the base entry as well as any
   63  * entry with a version number {@code i} where {@code 8 < i < n}.

So the "versions/{n} always overrides the "base entry", as actually we don't
have any info regarding the "version" of those base entries. Maybe I'm missing
something here?

-Sherman




On 01/28/2016 11:09 AM, Xueming Shen wrote:
> Steve,
>
> What's the purpose of having a dedicated "JarFile.runtimeVersioned"? Based on
> its only usages at ln#356 and #381, it appears, shouldn't getVersion() simply
> returns Release.valueOf(version)?
>
> sherman
>
> On 01/27/2016 03:37 PM, Steve Drach wrote:
>>> I'm still wondering about the phrase "root entry" as it continues to give the impression (to me anyway) that it's a resource in the root directory. I think "root" works in the JEP because it deals with simple resources like A.class and B.class that are in the root directory but it's confusing when there resources with a slash in the name. Add to this is the META-INF/versions/<n>  directories which are roots for the version specific resources. I think part of     the confusion is that the first mention of "root entry" is in the second paragraph where it has "overrides the unversioned root entry" without defining what it means. In summary, I'm wondering whether you would be up for change the terminology so that "root entry" isn't in the javadoc?
>> I’ve released a new webrev, http://cr.openjdk.java.net/~sdrach/8132734/webrev.04/index.html<http://cr.openjdk.java.net/~sdrach/8132734/webrev.04/index.html>  that addresses the above issue.
>>
>