On 10/14/15 4:04 PM, Steve Drach wrote:
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.
It does not sound right. The "exported public interface" of a jar file, or a multi-release-jar file is NOT those root entries, but the name of those entries. As the updated/newly added spec says, "The returned JarEntry is the versioned entry corresponding to the given root entry NAME prefixed with the string META-INF/versions/{n}...", So the returned entry should be the one that represents the "versioned entry", with the content of the entry and the meta data of the entry (the compressed size, the various timestamps, the comment...) form the versioned entry, not the root one, if there is a matched versioned entry. The implementation seems not follow this spec, it return the entry that actually is for the root entry, with a link to the versioned one, which serves the purpose of getting the corresponding input stream correctly, and make the verifier work (by simply passing the linked versioned to the verifier). However, all the meta data, accessible from the JarEntry APIs are all "broken", the attributes, certificates and the codeSigners are from the root entry. If my reading is correct, I'm not sure how it can work if someone wants to "verify" an individual signed entry by himself via security APIs, with all meta data from the root entry and the data itself from the versioned entry. I'm not sure if it is a good idea, from performance perspective, to add a "versionEntry" field into the JarEntry to support this feature, given most of the jar files might not be multi-release-jar aware, and the Jar input& output streams dont work with a multi-release jar directly. Why should they all pay a runtime price for it. If we really have to add an extra field, the JarFileEntry might be a better place, and it might be desired to define a new subclass JarFileEntryMR to use when the MR is enabled, instead of adding directly into the existing JarFileEntry. -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