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