This is the JDK change for JEP 176: JEP 176: Mechanical Checking of
Caller-Sensitive Methods [1]. Christian has posted the webrev for the
hotspot VM change a couple weeks ago [2].
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198429/webrev.00/
While it touches many files, the fix is simple and straight-forward for
review.
This fix annotates all methods that call Reflection.getCallerClass()
method with @sun.reflect.CallerSensitive annotation so that it enables
the VM to reliably enforce that methods looking up its immediate caller
class are marked as caller-sensitive. The JVM will set a new
caller-sensitive bit when resolving a MemberName and
java.lang.invoke.MethodHandleNatives.isCallerSensitive is upgraded to
query it directly.
The hand-maintained method list in MethodHandleNatives is removed.
A couple things to mention:
1. I am working on a fix for 8007035 that proposes to deprecate
SecurityManager.checkMemberAccess method as it requires the caller’s
frame to be at a stack depth of four, which is fragile and difficult to
enforce.
2. NashornScriptEngineFactory.getAppClassLoader()
The change is to workaround the issue until 8009783 is resolved.
The current implementation walks the stack to find the classloader of
the user context that NashornScriptEngine is running on which is
fragile. Also other script engine implementations may require similiar
capability. 8009783 has been filed to revisit the scripting API to pass
the user "context" to the script engine rather than relying the
implementation to find it magically.
Thanks
Mandy
[1] http://openjdk.java.net/jeps/176
[2]
http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008915.html
