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

[Steve Drach]

> On Jan 25, 2016, at 8:54 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

Somehow I missed this, sorry for the delayed response.

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

Base entries imply to me the entries that are the “base” of the jar file.  All multi-release jar files have to have a set of base entries that, as a whole, export the  public API of the jar file (whether it’s multi-release or not).  Versioned entries “override” base entries.  I could have said “Represents base entries” but that seems a little circular.  Actually base entries are the set of root entries minus the set of entries in the META-INF/versions directory ;-)

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

To me they are a resource in the root directory, but I see your point.

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

Let me see what I can do.