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

Paul Sandoz paul.sandoz at oracle.com
Wed Nov 4 09:01:10 UTC 2015

Hi Steve,

Hi Steve,

I don’t think we need to cache versioned entries (as we discussed a while back). For class loading it’s likely to increase memory costs without any performance benefit (if anything a performance decrease). It’s easy to add back later on if we have data that suggests otherwise.

We can reduce the search space for searching for versioned entries by setting the lower bound of the base version to one minus the first Java major release that has runtime support for multi-release jar files i.e. 8 as it currently stands.

 312      * @throws IllegalStateException if called after an entry has been read

  … after an entry has been obtained (see ….)

You might need some further clarification in setVersioned/setRuntimeVersioned itself describing the lifecycle e.g.

  this method may be called one or more times after construction and before the first operation that obtains an entry,
  after which the jar file configuration’s is considered immutable, and subsequent calls to this method will result in an ISE.


> On 3 Nov 2015, at 18:11, Steve Drach <steve.drach at oracle.com> wrote:
> Please review the latest webrev that addresses the issue raised in Sherman’s comments below, with my comments interspersed in-line.  The changes between this webrev and the last one are in the definition and use of the ismultiRelease() method and the introduction of a configuration lock, the boolean configured, that prevents setting the version after an entry has been read from the jar file.  As a consequence of the configuration lock, I had to modify a couple tests and add a new one.
> Issue: https://bugs.openjdk.java.net/browse/JDK-8132734
> JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305
> Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/

More information about the core-libs-dev mailing list