On 01/28/2016 11:28 AM, Steve Drach wrote:
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;
...
 381             return runtimeVersioned ? Release.RUNTIME : 
Release.valueOf(version);

What I meant is that if "version" is final and RUNTIME_VERSION is static final, 
why
do we need the middle-man "runtimeVersioned". And it appears the implementation
is doing at 381 is always actually to return Release.valueOf(version)?

It returns Release.valueOf(version) if "runtimeVersioned" is false. But in case 
of
"runtimeVersioned" is true, it means "version == Release.RUNTIME" at ln#356,
so you can also return Release.valueOf(version)? I'm confused, what did I miss?

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.


Reply via email to