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.
