invoking a interface default method from within an InvocationHandler

[Peter Levart]

On 10/20/2014 11:25 AM, Cédric Champeau wrote:
> For what it's worth, in Groovy, we have two separate pathes to "implement
> classes at runtime", that is to say generating proxies. In the case of an
> interface, we rely on the JDK proxy just because it is *much* faster than
> generating a class through ASM. I mean that generating a class in ASM is
> orders of magnitude slower (at least in our case) than relying on the JDK
> proxy adapters. Of course, it then depends on how often the method is
> called, because at some point a generated class will be faster, but so far,
> the choice we made is better in practice, because lots of people do not
> realize that if they do "foo as SomeInterface" in a loop, they are
> generating a new proxy for each call...

New proxy instance, not proxy class, right? j.l.r.Proxy API has a cache 
and only creates one Proxy class for a particular list of interfaces...

I agree that sun.misc.ProxyGenerator can be much faster at generating 
new class than ASM. But it's also more difficult to program/change. So 
it depend on what changes would be necessary...

Regards, Peter

>
> 2014-10-20 11:19 GMT+02:00 Paul Sandoz <paul.sandoz at oracle.com>:
>
>> 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.
>>
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>
>>
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20141022/38f7c789/attachment.html>