invoking a interface default method from within an InvocationHandler

[Paul Sandoz]

On Oct 16, 2014, at 12:43 PM, Remi Forax <forax at univ-mlv.fr> wrote:

> 
> On 10/15/2014 06:54 PM, Paul Sandoz wrote:
>> Hi Remi,
>> 
>> I did some brief evaluation of this area.
>> 
>> MethodHandleProxies.asInterfaceInstance currently does not support proxying to default methods. An InternalError will be thrown if a default method is invoked. It should be possible to fix using a trusted internal IMPL_LOOKUP to look up MHs that invokespecial. I believe this should be safe under the context of proxying.
> 
> Another solution is to do not rely on j.l.r.Proxy to implement asInterfaceInstance but to generate a proxy using ASM,
> in that case, handling default methods is easy, just do nothing (i.e. do not override a default method).
> It will also solve the fact that the proxies generated by asInterfaceInstance are currently super slow
> because of the InvocationHandler API require boxing.

That's a good point, it's more involved and it would be nice to reuse implementing classes keyed off the functional interface, since a field can be defined for the proxying MH. Hmm... i wonder if we can leverage InnerClassLambdaMetafactory.


> 
> The real solution in my opinion is to create yet another API,

Yes, i am thinking just in the 9 time-frame, beyond that, as you indicate below, there is much more scope to improve this area (via invoke or a class dynamic).

Paul.

> lets call it proxy 2.0 that takes an interface and a bootstrap method
> as parameter and generate a class that will call the BSM when calling a method of the proxy class the first time
> (the BSM will be called with a 4th parameter which is a method handle corresponding to the called method
> so one can use MHs.reflectAs to get the corresponding j.l.r.Method object if necessary).
> For a default method, the 4th parameter will be a method handle created with findSuper, so a user can choose
> to implement it or to delegate to this mh.
> And asInterfaceInstance is just a foldArguments between the method handle taken as parameter and
> an exactInvoker (or a genericInvoker if parameter types mismatch).
> 
> Compared to a j.l.r.Proxy, the proxy 2.0 API also need a way to store fields (or at least values) inside the generated proxy class
> and a way to query that fields inside the BSM. This can be done exactly like this is done by the lambda proxy,
> instead of returning a proxy class, the proxy 2.0 API will return a method handle that acts as a factory for creating
> proxy instances of the proxy class (if the factory takes no arguments, as for the lambda proxy, the same constant object can be returned).
> To get a mh getter from inside the BSM, because the BSM already have the lookup object, all you need is a convention that says
> that the field names are something like arg0, arg1, etc. 
> 
> The nice thing about this API is that it cleanly separate the information that can be process from proxied interface(s)
> (by example, JavaEE annotations) and the ones, more dynamic, that are specific to a proxy instance.
> It also removes one level of indirection compared to the InvocationHandler proxy. 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20141017/e5d97992/signature.asc>