java.lang.reflect.Proxy and default methods

Ali Lahijani alahijani at gmail.com
Sat Sep 1 14:44:23 PDT 2012


On Tue, Aug 28, 2012 at 5:05 PM, Peter Levart <peter.levart at marand.si> wrote:
> On Tuesday, August 28, 2012 02:32:26 PM Olexandr Demura wrote:
>> - 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?

An array MethodHandle[] will do. It will we of the same length as the
array of interfaces passed to Proxy.newProxyInstance() and will
contain default implementations in the same order.

>>
>> 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