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.
