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

Steve Drach steve.drach at oracle.com
Wed Oct 14 23:04:16 UTC 2015


> Any reason the JarEntry.get/setSize() are the only ZipEntry methods get overridden?

It didn’t seem necessary.  The root entries are the “public interface”, we’re just providing aliased entry contents.

> 
> -Sherman
> 
> On 10/14/2015 09:07 AM, Steve Drach wrote:
>> Hi,
>> 
>> Let’s try again, this time there are tests.  Please review the following webrev that adds support for multi-release jars as specified in JEP-238.
>> 
>> 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/
>> 
>> A multi-release jar file is a jar file that contains a manifest with a main attribute named "Multi-Release", and also contains a directory "META-INF/versions" with subdirectories that contain versioned entries segregated by the major version of Java platform releases. A versioned entry, with a version n, in the "META-INF/versions/{n}" directory overrides the unversioned root entry as well as any entry with a version number i  where i<  n.
>> 
>> The changes in this webrev implement an aliasing mechanism in JarEntry so that when a JarFile client retrieves a JarEntry, the data from the entry pointed to by the alias is returned.  There are methods to configure whether or not aliasing is enabled, and if it is, which version of an entry the alias points to.
>> 
>> When a JarFile is used by a class loader to load class resources, the default version retrieved is the runtime version of the Java platform (i.e. a version 9 entry is returned when the platform is JDK 9).  This mechanism can be configured by System properties.
>> 
>> Thanks,
>> Steve
> 




More information about the core-libs-dev mailing list