RFR: 8152733: Avoid creating Manifest when checking for Multi-Release attribute

Claes Redestad claes.redestad at oracle.com
Fri Mar 25 01:06:31 UTC 2016


the integration of the multi-release jar feature[1] caused a number of 
startup regressions, the primary cause of which was determined to be due 
to parsing manifests into java.util.jar.Manifest only to check for the 
Multi-Release attribute.

This can be avoided by reusing the logic already in place to check for 
the Class-Path attribute.

Bug:  https://bugs.openjdk.java.net/browse/JDK-8152733
Webrev: http://cr.openjdk.java.net/~redestad/8152733/webrev.01/

Some additional cleanup was done in this joint effort: Paul suggested a 
few improvements/cleanups to the search code, two anonymous classes to 
check settings could be removed, and - even though JarFile doesn't 
provide any thread-safety guarantees - the checkForSpecialAttributes 
method can be made thread-safe with a synchronized block at little to no 



[1] https://bugs.openjdk.java.net/browse/JDK-8132734

More information about the core-libs-dev mailing list