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.san...@oracle.com>:
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.
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
