java.lang.reflect.Proxy and default methods

[Peter Levart]

I think that the decision which methods to proxy and which not should be in 
the hands of InvocationHandler implementor not interface designer.

When new default methods are added to existing interfaces in JDK8, there will 
be no problem for existing 3rd party InvocationHandlers since there will not 
be any callers of those new methods yet (unless the JDK8 platform code itself 
called those new methods and custom implementations of those interfaces could 
be passed to this platform code via the pre-JDK8-existing APIs).

Gradually callers of new methods will emerge and InvocationHandlers will have 
to be adapted...

Regards, Peter

On Tuesday, August 28, 2012 04:05:09 PM Ali Lahijani wrote:
> 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