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

[Steve Drach]

>>> What's the purpose of having a dedicated "JarFile.runtimeVersioned”?
>> Consistency, so getVersion returns the same version as the version set when JarFile was constructed.
>> 
>>> Based on
>>> its only usages at ln#356 and #381, it appears, shouldn't getVersion() simply
>>> returns Release.valueOf(version)?
>> That might be confusing.  Also, having it consistent helps with testing.
>> 
> 
> 144     private final int version;
> 145     private final boolean runtimeVersioned;
> ...
> 355         this.version = MULTI_RELEASE_FORCED ? RUNTIME_VERSION : version.value();
> 356         this.runtimeVersioned = version == Release.RUNTIME;

Here “version” is a local argument and not equal to this.version.  It can take on the values Release.BASE, Release.VERSION_9, and Release.RUNTIME.  In the future we will see additional values like Release.VERSION_10 and Release.VERSION_11, etc.

but this.version can only have values of 8 and 9, and in the future 10, 11, etc.

this.version is a private implementation value and not publicly available.

> ...
> 381             return runtimeVersioned ? Release.RUNTIME : Release.valueOf(version);

the private method Release.valueOf(version) can only return Release.BASE and Release.VERSION_9

> 
> What I meant is that if "version" is final and RUNTIME_VERSION is static final, why
> do we need the middle-man "runtimeVersioned”.

So that getVersion will return Release.RUNTIME if the JarFile object was constructed with a Release.RUNTIME argument.

> And it appears the implementation
> is doing at 381 is always actually to return Release.valueOf(version)?

Except that it will return Release.RUNTIME if the private boolean runtimeVersioned is true

> 
> It returns Release.valueOf(version) if "runtimeVersioned" is false. But in case of
> "runtimeVersioned" is true, it means "version == Release.RUNTIME" at ln#356,

Yes, that what it means, keeping in mind the local variable version is not equal to this.version

> so you can also return Release.valueOf(version)?

You could but then one could  construct a JarFile object with Release.RUNTIME as it’s version, but getVersion would return Release.VERSION_9.  That’s what I meant by consistency, or in this case inconsistency.

> I'm confused, what did I miss?

I think you are focussing on a minor implementation detail.  Internally versions are small integer values, but externally, publicly, they are values of the Release Enum.

> 
> sherman
> 
> 
> 
>>> 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.
>>>> 
>