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

Sean Mullan sean.mullan at oracle.com
Mon May 11 20:01:16 UTC 2015


On 05/08/2015 07:13 PM, Mandy Chung wrote:
> On 05/05/2015 02:37 PM, Sean Mullan wrote:
>> So here is the new webrev:
>>
>> http://cr.openjdk.java.net/~mullan/webrevs/8075706/webrev.02/
>
> It now instantiates the built-in policy file class if "policy.provider"
> not set at the beginning.  Is it really necessary to load the custom
> policy provider class with boot loader first and then system class
> loader if not found?  I wonder if this can be simplified to use system
> class loader directly.  There might be some history hiding there?

I don't have the history but if I had to guess it might have been 
thought to be an optimization to avoid searching through the classloader 
hierachy to find the extension classloader. Now that we are using the 
system classloader, I don't think it is necessary and the code is much 
cleaner if I change it as you suggest. New webrev:

http://cr.openjdk.java.net/~mullan/webrevs/8075706/webrev.03/

>
> Nit: With diamond with anonymous classes support, you can simply use <>.

I tried that but I got a compiler error:

> error: illegal start of type
             AccessController.doPrivileged((PrivilegedAction<>)

It's possible this new feature doesn't work with lambda expressions and 
doPrivileged because of the additional cast that is required to 
distinguish the Action type. I'll experiment with it separately but for 
now I am just going to keep the code as-is.

--Sean



More information about the security-dev mailing list