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