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

Alan Bateman Alan.Bateman at oracle.com
Wed Feb 3 09:05:16 UTC 2016

On 03/02/2016 02:24, Steve Drach wrote:
> 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. 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.

I think the javadoc will need to also need to make it clear whether 
entries with names starting with META-INF/versions/ are returned.

I see you've added @since 9 to the existing methods, I assume you didn't 
mean to do this.

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.


More information about the core-libs-dev mailing list