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

[Alan Bateman]

On 25/03/2016 01:06, Claes Redestad 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 quite good.

You've replaced the precomputed good suffix shift which i think makes 
the Math.max in math a bit harder to read. A comment or just move a 
local for "j < len - 1 ? len : 1" would make it a bit easier to read.

It would be good to move the value of MULTIRELEASE_CHARS to its own line 
as the current line is requires scrolling when looking at the 
side-by-side diffs.

-Alan