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

[Steve Drach]

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

It makes sense to leave it in there because of the context.  It’s one of 2 things that differentiate JarFile from ZipFile
.
> 
> 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.

I’ll do that.

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

We felt that one constructor was sufficient on the theory that it’s use will be infrequent, at least initially.  And it’s easy to map a String to a File.

> 
> One other thing that I've been wondering about is the stream() and entries() methods. Has there been any discussion about these doing filter?

Not that I’m aware of.

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

Perhaps you can elaborate.