RFR: 8174222: LambdaMetafactory: validate inputs and improve documentation

Dan Smith daniel.smith at oracle.com
Sat Mar 23 15:13:29 UTC 2019


> 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?

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

Fixed.



More information about the core-libs-dev mailing list