Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK
Mandy Chung
mandy.chung at oracle.com
Wed Apr 3 02:56:12 UTC 2013
Here is the updated webrev per John's and Alan's comments:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198429/webrev.02/
In MethodHandles.java, it calls Class.getDeclaredMethod method to
determine if a SecurityManager subclass overrides checkMemberAccess.
It's called only if security manager is installed and it's a subclass.
If it calls Class.getMethod instead, it will look up its superclasses
and find the one in SecurityManager.class. For the case when the
subclass doesn't override CMA, the difference in overhead will be
throwing an exception vs. looking up CMA from the subclass and its
superclasses and create the Method instance. I don't have the
performance number to compare. This would be rare case and I tend to
think instantiating and throwing an exception would be comparable to the
reflection machinery. This check will go away when 8007035 is fixed
that will deprecate SecurityManager.checkMemberAccess [1] and I'm fine
going either way.
FYI. 7198429 has been used for the hotspot changeset and will be
resolved when it's integrated to jdk8/hotspot repo. The jdk changeset
will be using 8010117, a subtask for 7198429, as specified in @bug tags
in the tests.
Mandy
[1] http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/16885e702c88
[2]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-March/015547.html
On 4/2/2013 3:25 PM, Mandy Chung wrote:
> On 4/2/13 3:00 PM, Peter Levart wrote:
>> Hi Mandy,
>>
>> There could be:
>>
>> public class SM1 extends SecurityManager {
>> @Override
>> public void checkMemberAccess(Class<?> clazz, int which) {...
>>
>> and:
>>
>> public class SM2 extends SM1 { ... // no checkMemberAccess override
>>
>> now if if you take SM2.class.getDeclaredMethod("checkMemberAccess",
>> ...) it will throw NoSuchMethodException, but the method is overriden in
>> SM1. So I think it's better to use what John suggested (although not
>> using getDeclaredMethod, but getMethod instead):
>>
>> smgr.getClass().getMethod("checkMemberAccess",
>> ...).getDeclaringClass() == SecurityManager.class
>
> Are you concerned the overhead of an exception thrown that we should
> avoid?
>
> Mandy
More information about the core-libs-dev
mailing list