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

[Xueming Shen]

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