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.

_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Reply via email to