On Oct 18, 2014, at 6:59 PM, Peter Levart <peter.lev...@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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
