RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged
dean.long at oracle.com
dean.long at oracle.com
Thu Nov 1 19:21:07 UTC 2018
On 11/1/18 9:48 AM, Sean Mullan wrote:
> On 11/1/18 1:29 AM, dean.long at oracle.com wrote:
>> On 10/31/18 9:39 PM, Bernd Eckenfels wrote:
>>> http://cr.openjdk.java.net/~dlong/8212605/webrev.1/src/java.base/share/classes/java/security/AccessController.java.udiff.html
>>>
>>>
>>> In checkContext should the security manager be null checked first
>>> instead of last to optimize for the typical case? (If the side
>>> effects in that expression are desired it should be documented)
>>
>> I was following the example of createWrapper. The side-effects of
>> getInnocuousAcc() will only happen once, so the order shouldn't
>> matter here, except for performance reasons. I don't have a strong
>> opinion about the order, but it looks like the typical case for
>> createWrapper would also be the typical case for checkContext, so
>> maybe they both should be changed, if indeed a null security manager
>> is the more typical case.
>
> A null SM should be the more common case. I am ok with changing the
> order so the SM is checked first, but it should be done in both the
> createWrapper and checkContext methods. Alternatively, we could see if
> they could be combined to eliminate the duplicate code but that might
> not be practical from looking at them.
>
I don't see a way to do it without using a lambda or doing extra work in
one version, so I just changed the order for now. I also replaced
getCallerPD with the faster getProtectionDomain and removed a stale
comment about impliesCreateAccessControlContext being called by the VM.
It should be safe to remove now, but I left it in to minimize changes.
http://cr.openjdk.java.net/~dlong/8212605/webrev.3.incr/
http://cr.openjdk.java.net/~dlong/8212605/webrev.3/
dl
> --Sean
More information about the security-dev
mailing list