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

Alan Bateman Alan.Bateman at oracle.com
Mon Jan 25 16:54:05 UTC 2016

On 22/01/2016 23:10, Steve Drach wrote:
> Hi Alan, et. al.,
> I’ve released a new webrev that addresses all the issues you raised.
> http://cr.openjdk.java.net/~sdrach/8132734/webrev.03/index.html 
> <http://cr.openjdk.java.net/%7Esdrach/8132734/webrev.03/index.html>
> Specifically:
>> For Release then I have to admit that I dislike _9 and wonder if 
>> other options were considered? javax.lang.model.SourceVersion uses 
>> the RELEASE_xx convention for example.
> Changed to VERSION_9, i.e. Release.VERSION_9
>> Also I wonder about Release.ROOT and whether Release.UNVERSIONED was 
>> considered? In general the phrase "root entry" in the javadoc makes 
>> me think the root or top-most directory. An alternative that might be 
>> clearer is to say "unversioned entry" and define that term clearly in 
>> the class description.
> Changed to BASE, i.e. Release.BASE
This looks better. Release.BASE is probably okay although it still feels 
like Release.UNVERSIONED, esp. when it is defined as "Represents 
unversioned entries".

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?


More information about the core-libs-dev mailing list