Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

Mandy Chung mandy.chung at
Wed Apr 3 02:56:12 UTC 2013

Here is the updated webrev per John's and Alan's comments:

In,  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.


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