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

[Alan Bateman]

On 27/01/2016 23:37, 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/%7Esdrach/8132734/webrev.04/index.html> that 
> addresses the above issue.
>
Thank you, the javadoc is much clearer and readable now.

The first mention of multi-release JARs is in the first paragraph where 
it has "for processing multi-release jar files". I would be tempted to 
drop this from the first paragraph because the second paragraph 
introduces the concept.

In the second paragraph is has "The versioned entries are partitioned by 
the major version of Java platform releases, starting with release 9" 
and then it goes on to explain how versioned entries are partitioned. 
This has potential to confuse the reader as it gives an initial 
impression that the oldest version entry is 9 but then the says 8 < n. I 
realize the text is trying to say that Java SE 9 is the first release to 
support this but it could be confused. I would be tempted to just drop 
the mention of release 9 in this paragraph.

This may have come up before but JarFile has two sets of constructors, 
one takes the file path as a String, the other as a File. I just 
wondering about introduce a second constructor so that they match.

One other thing that I've been wondering about is the stream() and 
entries() methods. Has there been any discussion about these doing 
filter? Maybe it is too expensive and best left to the user of the API? 
Part of the context for asking is modular JARs of course.

-Alan