On Jul 2, 2013, at 7:00 AM, Jochen Theodorou <blackd...@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 <blackd...@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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
