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

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