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