RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation

[Remi Forax]

----- Mail original -----
> De: "daniel smith" <daniel.smith at oracle.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Samedi 23 Mars 2019 16:13:29
> Objet: Re: RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation

>> On Mar 21, 2019, at 8:58 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> 
>> +1 from me.
>> 
>> 
>>> http://cr.openjdk.java.net/~dlsmith/8174222/webrev.00/
>>> 
>>> 
>> 
>> AbstractValidatingLMF
>> ---------------------
>> 
>> I see you renamed most of the fields and params.  Most of these are
>> improvements, but it may be worth being more explicit in ambiguous cases.  For
>> example, there are two method names, so perhaps instead of `methodName` it
>> should be `interfaceMethodName` to make it clear this is the SAM method and not
>> the implementation method.
> 
> Good idea, done.
> 
>> I presume the SecurityException is something that was always thrown, and we are
>> just documenting it now.  Should that be wrapped in a LCE instead?
> 
> Yep, it's inherent in trying to crack MethodHandles. It's unusual enough that it
> seems like it's worth passing through—it's sort of a configuration problem for
> users?
> 
> Worth thinking about how that limitation impacts the language. I didn't try to
> test it, because I don't totally get how to trigger it, but it seems like you
> could write a valid Java program with a method reference and end up triggering
> the exception at runtime? Is that bad?

Hi Dan,
i don't think you can trigger the SecurityException by written an invokedynamic in the bytecode because by construction the Lookup object and the MethodHandle will use the same classloader,
see https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#secmgr

But you can trigger it by calling the bootstrap method directly from Java with a a security manager installed and a Lookup and a MethodHandle that come from two different classloaders.

[I've added John in CC, just to be sure i'm not saying something stupid]

> 
>> Accidentally lost the {@code ...} surrounding MethodHandle in class description.
> 
> Fixed.


Rémi