Omitting the "int" parameter would be a bad idea since it would prevent
wrappers. One could imagine a common interface to obtain the caller class where
the proper implementation is chosen via fallback, e.g.
- if available, use our new API (fastest?)
- else, try to use Reflection.getCallerClass (
Okay, but I don't think @CallerSensitive is necessary to prevent MethodHandles
from spoofing caller classes. I'll admit I don't know very much about
MethodHandle, what it does, or how its invocation methods are different from
Method.invoke(). In the code that I copied into this email from jvm.cp
Quick question for those of you that know anything about @CallerSensitive...
After looking at the code and experimenting some, I've discovered that
getCallerClass() doesn't actually keep going until it finds the first method
without @CallerSensitive. It only returns the caller of the caller. So,
On Jul 30, 2013, at 7:45 AM, Peter Levart wrote:
> I think there are various techniques to use new API when running on JDK8 and
> still use old API when running on JDK6 or 7. One way is to have 2 classes
> implementing the same interface or extending basic class where one is
> compiled with JD
"For caller-sensitive methods, the approach taken with new
Reflection.getCallerClass() is the right one, I think. There's no need to
support a fragile API when caller-sensitivity is concerned, so the lack of
"int" parameter, combined with annotation for marking such methods is correct
approach,
Hi Nick,
The @CallerSensitive annotation is an annotation that prevents some
other infrastructure, namely the MethodHandles, to "spoof" caller classes.
Try this:
MethodHandles.Lookup lookup =
MethodHandles.lookup().in(Object.class);
MethodHandle mh = lookup.findStatic(Class.c
