invoking a interface default method from within an InvocationHandler

[Jochen Theodorou]

Am 18.10.2014 18:59, schrieb Peter Levart:
[...]
> The complete solution will require new API, but the
> java.lang.reflect.Proxy API could be improved a bit too. With
> introduction of default interface methods it is somehow broken now.

I find this a bit strange.  A new API means at least JDK9. So JDK8 will 
stay broken in regards to the reflective Proxy. The only reason why we 
use it, is because it is really faster to create a reflective Proxy and 
use it for several cases. But basically it means we have no proxy 
solution in JDK8/9 for now that works for sure. Of course you can try a 
method handle with an invoke special, but how to get to the "private 
access" allowing lookup constructor? With reflection a security manager 
may prevent it (and does so on Google app engine for example)... Not to 
mention that it sounds wrong as well. The only other way is then "slow" 
class generation at runtime, with all the class loader fun, and again 
possible security managers forbidding things.

> Default interface methods enable interface evolution, but break existing
> Proxy InvocationHandler(s) which are not prepared to handle new methods.

imho, that's only partially the problem. It depends on the usage of the 
proxy. If the purpose of the proxy is to simply redirect each and every 
method call to the proxies object, then it will work just fine as 
before. If you say it makes sense to not to redirect the default 
methods, you have lost the game, since there is no instance to make the 
reflective invocation on

> So perhaps a small improvement to Proxz API could be to add new factory
> method that takes an additional a boolean flag indicating whether
> generated proxy should override default methods and forward their
> invocation to InvocationHandler or not. An all-or-nothing approach. I
> know that even that is not trivial. Generated proxy class can implement
> multiple interfaces and there can be conflicts. In that case, the
> easiest solution is to bail out and refuse to generate a proxy class
> with such combination of interfaces.

yeah, I guess I simply have a problem with the assumption that default 
methods are intended to allow a backwards compatible way of interface 
evolution. But the conflict case surely is the end of the line for this.

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org