sun.reflect.Reflection.getCallerClass(int) is going to be removed... how to replace?
John Rose
john.r.rose at oracle.com
Tue Jul 2 11:13:45 PDT 2013
On Jul 2, 2013, at 7:00 AM, Jochen Theodorou <blackdrag at GMX.ORG> wrote:
> for example... Class.forName(String)
That's a good example.
If you call Class.forName via reflection, it will sense its immediate caller, which (depending on your system) might be a random frame in your language runtime. This approach gets wrong answers by accident, which sometimes causes subtle problems. When your language runtime has a different privilege level than the script, you can get confusion about which privilege level is supposed to apply to the requested class name resolution. This could lead to untimely surprises.
If you call Class.forName via a method handle in early versions of JDK 7, similar things can happen. In more recent versions of JSR 292, when you look up a method handle that is known to be caller-sensitive, the call to Lookup.findStatic (for example) returns a "caller-bound" version of the method handle, which is permanently bound to the lookup class of the lookup object you used to find the method handle. Then, regardless of where that MH gets installed or used (in some random MH graph, or directly in an invokedynamic) the caller sensitive aspect is always the same.
(Fine print: This behavior is a corollary of the originally specified nature of MHs in terms of their "bytecode behavior", since the bytecode behavior of a CS method includes the class holding the bytecodes performing the invoke. Note that this does not work for publicLookup, since that guy doesn't possess a knowable containing class for his bytecode behaviors.)
The upshot of all this is that if you encapsulate your CS method calls in method handles obtained from a BSM or MethodHandles.lookup, your code won't be sensitive to the dynamic context of those calls.
On Jul 2, 2013, at 5:56 AM, Jochen Theodorou <blackdrag at GMX.ORG> wrote:
> A simple example is a Groovy program calling
> ResourceBundle#getBundle(String)
The same considerations apply to resource bundles also.
Basically, if you use Method.invoke on a caller sensitive method, it may sense a random caller. Use method handles for these cases, if possible.
— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20130702/114f389f/attachment-0001.html
More information about the mlvm-dev
mailing list