java.lang.reflect.Proxy and default methods

Peter Levart peter.levart at marand.si
Tue Aug 28 05:35:23 PDT 2012


On Tuesday, August 28, 2012 02:32:26 PM Olexandr Demura wrote:
> It can be solved easier. Proxy is build around SAM InvocationHandler.
> This pair can be rebuild:
> - add new method to InvocationHandler
> default Object invoke(Object proxy, Method method, MethodHandle
> defaultCode, Object[] args) {
>   return invoke(proxy, method, args);
> }
> - make Proxy use that new `invoke` instead of current one.

Nice use of MethodHandle.

The problem with this approach I see is what to do with conflicting default 
methods inherited from multiple interfaces. Have a Map<Class, MethodHandle> 
passed to the InvocationHandler?

Regards, Peter

> 
> BTW, what are the plans for default method code access thru reflection?
> 
> 2012/8/28 Peter Levart <peter.levart at marand.si>:
> > On Tuesday, August 28, 2012 11:18:55 AM Peter Levart wrote:
> >> Currently java.lang.reflect.Proxy treats default interface methods the
> >> same
> >> as abstract methods (it passes their invocations to the
> >> InvocationHandler),
> >> which is the right thing to do if current platform interfaces like
> >> Iterator
> >> will have some abstract methods turned into default methods.
> >> 
> >> But if at the same time interfaces like Iterable get new default methods,
> >> libraries that expose proxies to those interfaces will have to be
> >> prepared
> >> (modified) to handle invocations to those new methods.
> >> 
> >> Sometimes the library writer might just want to pass default method
> >> invocations to the default method implementations in the interface. Will
> >> there be a reflection facility to call super interface methods on the
> >> proxy
> >> instance or is there anything else planned to facilitate this?
> > 
> > One way to do that without support for calling super default methods using
> > reflection might be to overload java.lang.reflect.Proxy factory methods
> > with variants that take additional "boolean proxyDefaultMethods"
> > parameter so that when passed as "true" the proxy will act as currently
> > (pass default method invocations to InvocationHandler) and when passed as
> > "false", default methods in interfaces will not be "overriden" in
> > generated Proxy class so that default implementations in interfaces will
> > take over.
> > 
> > If someone wants to be selective (proxy some default methods and not proxy
> > others), she could get the desired behaviour by creating a private sub-
> > interface which re-abstracts selected default methods and use the sub-
> > interface in the Proxy factory. The same "technique" could be used to
> > resolve conflicting default methods from multiple interfaces.
> > 
> > Some applications that want to be more dynamic might stil prefer
> > reflective
> > access to interface super methods in the proxy...
> > 
> > Regards, Peter


More information about the lambda-dev mailing list