On Oct 16, 2014, at 12:43 PM, Remi Forax <fo...@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. >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
