RFR 8206955 MethodHandleProxies.asInterfaceInstance does not support default methods

[Paul Sandoz]

Hi Peter,

> On Jul 11, 2018, at 8:15 AM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> Hi Paul,
> 
> The patch looks ok.

Thanks.


> I hope IMPL_LOOKUP has access to all methods (even if located in package-private interfaces and/or in concealed packages of modules)?
> 

I think it should be ok, because IMPL_LOOKUP is used it does not matter what is passed as the specialCaller since IMPL_LOOK is trusted and a full power lookup will be given for Lookup.in. (FWIW because this code is in j.l.invoke it is currently not possible to instantiate a lookup). Since access control is gated by the invokevirtual to the interface method it should be ok to use the full powerful lookup.


> Just a thought... Would it be possible to implement this API in terms of LambdaMetafactory ?
> 

It’s definitely possible to do better spinning an explicit proxy class rather the current proxy class deferring to an invocation handler.

My focus with this fix is to make it functional without unduly increasing the cost of when default methods are not invoked, and not focus on the performance right now. 

There are some subtle differences between functional interfaces and this functionality which was introduced prior to the latter e.g. it's possible to explicitly declare overloaded abstract methods whose return/parameter types are compatible with the target type.

Paul.

> Regards, Peter
> 
> 
> On 07/11/2018 12:43 AM, Paul Sandoz wrote:
>> Hi,
>> 
>> Please review this fix to MethodHandleProxies.asInterfaceInstance to support default methods:
>> 
>>   http://cr.openjdk.java.net/~psandoz/jdk/JDK-8206955-mh-func-iface-proxy-default-methods/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk/JDK-8206955-mh-func-iface-proxy-default-methods/webrev/>
>> 
>> It probably requires a CSR, which i shall do after this review.
>> 
>> Thanks,
>> Paul.
>