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
