invoking a interface default method from within an InvocationHandler

[Paul Sandoz]

On Oct 18, 2014, at 6:59 PM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> Hi Paul, Remi,
> 
> 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. Default interface methods enable interface evolution, but break existing Proxy InvocationHandler(s) which are not prepared to handle new methods. 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.

It would also be useful to investigate a safe mechanism so that an InvocationHandler implementation can call a default method, which then allows an impl to explicitly deal with conflicts.


> 
> A starting point could be to re-implement current functionality using ASM and then start experimenting with different approaches. What do you think?
> 

Not sure replacing the bytecode generating implementation, in sun.misc.ProxyGenerator, with an ASM equivalent will really help all that much functionality wise, that may be nice from a unification perspective but does introduce some risk. A quicker route might be to work out how to filter out the default methods that are overridden in the existing code.

Paul. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20141020/4e1632d8/signature.asc>