RFR: JDK-8075706 : Policy implementation does not allow policy.provider to be on the class path

[Sean Mullan]

On 05/08/2015 11:11 AM, Alan Bateman wrote:
> On 05/05/2015 22:37, Sean Mullan wrote:
>> I was trying to avoid too many changes, but in the end I decided it
>> was better to refactor some of this code into a new method. So here is
>> the new webrev:
>>
>>     http://cr.openjdk.java.net/~mullan/webrevs/8075706/webrev.02/
>>
>> Changes include:
>>
>> - bootstrapping code moved to new method named loadPolicyProvider
>> - added Alan's suggestion to fallback to SCL only if CNFE is thrown
>> - instantiated default policy provider directly instead of using
>> reflection if property has not been changed or is not set
>> - addressed Mandy's comment about formatting
>> - enhanced test to cover more cases
>>
> I don't have cycles to look at the test but the changes to PolicyFile
> looks okay, and in line with what was there previously. As getting the
> value of the security.provider property involves a permission check then
> I assume that isSet is guaranteed to be called before this code
> executes, otherwise there would be another potential way to get
> recursive initialization.

I don't think it is an issue, because it gets the property inside a 
doPriv and thus only system code is on the stack and the ACC is null, 
and so it never calls the policy provider.

> One small inconsistency is that Class.forName when trying to locate the
> provider on the boot loader doesn't run the static initializers whereas
> it does for the attempt to locate it via the system class loader.

Yes, that was there previously.

--Sean