Can you describe if there is any effect on signed jars? Including:

1. Will jarsigner be able to sign such a jar? Are all items inside signed? If 
you sign a jar using jarsigner from different versions of JDK, will there be 
any difference?

2. Will jarsigner be able to verify such a jar? Will it only verify entries for 
the current version or all? Will jarsigner from an old JDK verify the new jar?

3. As I know, JarFile has 2 ways to verify a jar file, one using public APIs. 
One through SharedSecrets.setJavaUtilJarAccess() which can call more methods. 
Have you confirmed both work?

Yes, I'd also like some tests on these.

Thanks
Max

> On 2015年9月30日, at 上午2:13, Steve Drach <steve.dr...@oracle.com> wrote:
> 
> Hi,
> 
> 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 
> <https://bugs.openjdk.java.net/browse/JDK-8132734>
> JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 
> <https://bugs.openjdk.java.net/browse/JDK-8047305>
> Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-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

Reply via email to