Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

[Peter Levart]

On 07/30/2013 06:46 PM, MacGregor, Duncan (GE Energy Management) wrote:
> I can understand the worry about exposing @CallerSensitive methods, at
> least for the case of lookup.in() as I'm sure it could be used to open an
> exciting can of worms, but the current limitation doesn't feel quite
> right. I wonder whether solution could go something like:
>
>   1. I have a lookup from an invokeDynamic bootstrap. This should be
> full-powered with its lookupClass being the class containing the
> invokeDynamic.
>   2. Getting a new Lookup object using the lookup.in() method should return
> something that can lookup @CallerSensitive methods that are visible to it,
> but it's 'caller' remains that of the original lookup class.

I view lookup.in(requestedLookupClass) as a means to "change" the lookup 
class *and* the caller class at the same time. I think the new Lookup 
object obtained this way is never more capable of looking-up members 
than the original Lookup object but can be less capable, so if you 
already have the Lookup object avaliable from the invokeDynamic 
bootstrap, then this is the right object to use.

The case I'm after is when there's no invokeDynamic involved and the 
caller class must be obtained in the caller-sensitive way (by some 
Reflection.getCallerClass() method or such). It would be useful if under 
some constraints (perhaps the visibility of called class from the 
calling class) the called method which would be marked as 
caller-sensitive could obtain a Lookup object for the calling class 
which would allow looking up other @CallerSensitive methods, like:

@CallerSensitive
public void myCallerSensitiveMethod() {
     Lookup callerLookup = 
MethodHandles.lookup().in(Reflection.getCallerClass());
     MethodHandle targetCallerSensitiveMH = callerLookup.lookupXXX(....);
     targetCallerSensitiveMH.invoke(...);
}

Regards, Peter

> Regards, Duncan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20130730/d52f4982/attachment.html