java.lang.reflect.Proxy and default methods

Ali Lahijani alahijani at gmail.com
Sat Sep 1 14:55:00 PDT 2012


We can add an @WasAbstract annotation to signify any method, in a
class or interface, which currently has a body but was abstract in a
previous version. At least it is good for documentation.

A default method of an interface would be passed to an (old)
InvocationHandler only if it has an @WasAbstract. Otherwise the
(firsts?) default implementation would be used.

New InvocationHandlers can use the new API if they need additional control.

On Tue, Aug 28, 2012 at 6:25 PM, Olexandr Demura
<oleksander.demura at gmail.com> wrote:
> Good point. New feature `default` erased distinction between
> interfaces and abstract classes from the Proxy point of view.
>
> With new defaulted `invoke` all invocations on old InvocationHandler
> will come thru old `invoke`, no matter if they are defaulted or not.
> Usually old InvocationHandler should be able to treat any method at
> least because its a general Proxy anyway.
>
> 2012/8/28 Ali Lahijani <alahijani at gmail.com>:
>> 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


More information about the lambda-dev mailing list