> On Mar 21, 2019, at 8:58 AM, Brian Goetz <brian.go...@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.
