On 30/07/2013 16:58, "Charles Oliver Nutter" <head...@headius.com> wrote:
>On Tue, Jul 30, 2013 at 7:17 AM, Peter Levart <peter.lev...@gmail.com> >wrote: >>Now that is the question for mlvm-dev mailing list: Isn't preventing >>almost >> all Lookup objects obtained by Lookup.in(RequestedLookupClass.class) >>from >> obtaining MHs of @CallerSensitive methods too restrictive? > >Probably. It seems to me that @CallerSensitive is no different from >exposing private methods or fields through a MH. Perhaps it should >recalculate caller when it's called, perhaps it should calculate it at >lookup time, but not being retrievable at all seems like overkill. I >will grant that overkill was probably the quickest and safest solution >at the time. 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. Regards, Duncan. _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
