Thanks for the comments Alan. Responses in-line.
I created a new webrev, http://cr.openjdk.java.net/~sdrach/8132734/webrev.05/ <http://cr.openjdk.java.net/%7Esdrach/8132734/webrev.05/>, that implements what I outlined above. In particular I enhanced the JarEntryIterator class and I added additional commentary to the entries() and stream() methods. I also added a new test, MultiReleaseJarIterators, to test entries() and stream().
I think having stream and entries do this is right although I would like to see some performance data if possible.
I’ll see what I can do. I suspect the non-multi-release jar will be very comparable since there’s just a couple boolean tests that were added for this case.
Also I would expect that if a JAR file is not mult-release but the library opens it with Release.RUNTIME to perform the same as opening the JAR file with the Release-less constructors.
Perhaps. There is a slightly different path with an additional method call and boolean test in this case, but I’ll try to get some metrics here too.
I think the javadoc will need to also need to make it clear whether entries with names starting with META-INF/versions/ are returned.
It was a bit difficult to explain in a succinct way, but the careful reader should be able to infer that the META-INF/versions/ entries are not returned when the constructor with the Release argument is invoked. I’ll try to add some additional detail.
I see you've added @since 9 to the existing methods, I assume you didn't mean to do this.
I did mean to do it, but now that you mention it, I see it was a mistake. I’ll fix that.
At some point then we need to discuss how RUNTIME_VERSION is computed. Iris (via Mandy) has pushed jdk.Version to jdk9/dev but having it exported by java.base conflicts with the design principles in JEP 200. Moving it to another module means that code in java.base cannot use it and thus the JAR file can't use it.
I guess I need to wait until that settles down a bit.