java.lang.reflect.Proxy and default methods

[Ali Lahijani]

On Tue, Aug 28, 2012 at 3:02 PM, Peter Levart <peter.levart at marand.si> wrote:
> 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.

In any event, an InvokationHandler written against the current API
should receive all the methods that it currently receive. That is, to
an old InvokationHandler, the new Collection::forEach does not exist
at all, while Collection::isEmpty is an ordinary abstract method which
it handles, in spite of the fact that they both have default
implementations.

So maybe we need an annotation on methods like Collection::isEmpty and
Iterator::remove where we are adding default implementations to
existing methods to differentiate them from methods are added to an
existing interface. Or, maybe I am missing something obvious here?

Ali