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

Paul Sandoz paul.sandoz at oracle.com
Fri Mar 25 12:05:55 UTC 2016


> On 25 Mar 2016, at 02:06, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Hi,
> 
> 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 cost.
> 

This looks good. Thanks for noticing the existing code for class-path parsing.

I agree with Alan, a comment as to why the good suffix shift can be reduced to a comparison would be helpful.

Paul.

> Thanks!
> 
> /Claes
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8132734




More information about the core-libs-dev mailing list