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

[Steve Drach]

> On Nov 4, 2015, at 1:01 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> 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.

Okay, I’ll take that code out.  As you said, it’s easy to add back if needed.

> 
> 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.

Yes, I can do that.  I’ll need to change the test jar file from versions 8 and 9 to versions 9 and 10 because we won’t see the version 8 classes in the current test jar and it’s nice to have a test jar with more than one version.

> 
> 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.

Okay.

> 
> Paul.
> 
>> 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/
>> 
>