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