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.
-Alan.
More information about the core-libs-dev
mailing list