This is rudimentary off the top of my head, but the following code produces this output:
It took a total of 9.022382 seconds using $Proxy0. It took a total of 5.528322 seconds using TestAnnotationTrainer$Foo$$EnhancerByCGLIB$$c462c19e. It took a total of 5.084160 seconds using JavassistUtilsGenerated_1. I'm sure it's not the most scientific, but it's a start. private static void benchmark(Foo[] foos, long n) { final long totals[] = new long[foos.length]; for (int count = 0; count < n; ++count) { for (int i = 0; i < foos.length; i++) { Foo foo = foos[i]; final long before = System.nanoTime(); for (int j = 0; j < 10000; ++j) { foo.bar(); } totals[i] += System.nanoTime() - before; } } for (int i = 0; i < foos.length; i++) { Foo foo = foos[i]; System.out.println(String.format("It took a total of %f seconds using %s.", totals[i] / 1000000000.0, foo.getClass().getSimpleName())); } } //---------------------------------------------------------------------------------------------------------------------- // Inner Classes //---------------------------------------------------------------------------------------------------------------------- public static interface Foo { public void bar(); } public static class FooImpl implements Foo { @Override public void bar() { } } //---------------------------------------------------------------------------------------------------------------------- // main() method //---------------------------------------------------------------------------------------------------------------------- public static void main(String[] args) { CglibProxyFactory cglib = new CglibProxyFactory(); JdkProxyFactory jdk = new JdkProxyFactory(); JavassistProxyFactory javassist = new JavassistProxyFactory(); ObjectProvider<Foo> provider = ObjectProviderUtils.<Foo>constant(new FooImpl()); Foo cglibFoo = cglib.createDelegatorProxy(provider, Foo.class); Foo jdkFoo = jdk.createDelegatorProxy(provider, Foo.class); Foo javassistFoo = javassist.createDelegatorProxy(provider, Foo.class); final Foo[] foos = new Foo[]{jdkFoo, cglibFoo, javassistFoo}; benchmark(foos, 100000); } } On Thu, Aug 1, 2013 at 11:15 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > hehe, do you have figures? > > when JIT did its work reflection is almost free. You can update the asm > proxy factory to handle 3 implementations but it is not worth it IMO > > *Romain Manni-Bucau* > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* > *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* > *Github: https://github.com/rmannibucau* > > > > 2013/8/1 James Carman <ja...@carmanconsulting.com> > >> You're going to lose the benefit of having ASM if you just end up >> using reflection to call the methods anyway aren't you? The Javassist >> code actually generates Java code that actually calls the real method >> on an instance of the appropriate type. That's what makes it faster. >> >> On Thu, Aug 1, 2013 at 10:57 AM, Romain Manni-Bucau >> <rmannibu...@gmail.com> wrote: >> > No, but believe me you want a handler (this one or invoker) to maintain >> the >> > code and keep it easy. >> > >> > *Romain Manni-Bucau* >> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >> > *Blog: **http://rmannibucau.wordpress.com/*< >> http://rmannibucau.wordpress.com/> >> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >> > *Github: https://github.com/rmannibucau* >> > >> > >> > >> > 2013/8/1 Matt Benson <gudnabr...@gmail.com> >> > >> >> That's my point; it doesn't. >> >> >> >> >> >> On Thu, Aug 1, 2013 at 9:49 AM, James Carman < >> ja...@carmanconsulting.com >> >> >wrote: >> >> >> >> > Does the ASM API require a java.lang.reflect.InvocationHandler? >> >> > >> >> > On Thu, Aug 1, 2013 at 10:41 AM, Romain Manni-Bucau >> >> > <rmannibu...@gmail.com> wrote: >> >> > > Well for the maintainance it is easier (and not really slower) to >> use a >> >> > > little abstraction. InvocationHandler/Inoker is fine. Since JdkProxy >> >> uses >> >> > > the exact same code i throught it could be shared. >> >> > > >> >> > > *Romain Manni-Bucau* >> >> > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >> >> > > *Blog: **http://rmannibucau.wordpress.com/*< >> >> > http://rmannibucau.wordpress.com/> >> >> > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >> >> > > *Github: https://github.com/rmannibucau* >> >> > > >> >> > > >> >> > > >> >> > > 2013/8/1 Matt Benson <gudnabr...@gmail.com> >> >> > > >> >> > >> The behavior of proxies is specified by Invokers, ObjectProviders, >> and >> >> > >> Interceptors. Each ProxyFactory implementation bridges from these >> >> > >> interfaces to the most appropriate mechanism specific to the target >> >> > >> technology. In the case of ASM, I would think that would be direct >> >> calls >> >> > >> against the proxy interface implementations themselves. >> >> > >> >> >> > >> Matt >> >> > >> On Aug 1, 2013 9:21 AM, "Romain Manni-Bucau" < >> rmannibu...@gmail.com> >> >> > >> wrote: >> >> > >> >> >> > >>> a sed shold almost work but the issue is the same: the code is >> >> > >>> duplicated, no? is there invoker elsewhere? >> >> > >>> >> >> > >>> *Romain Manni-Bucau* >> >> > >>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >> >> > >>> *Blog: **http://rmannibucau.wordpress.com/*< >> >> > http://rmannibucau.wordpress.com/> >> >> > >>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >> >> > >>> *Github: https://github.com/rmannibucau* >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> 2013/8/1 Matt Benson <gudnabr...@gmail.com> >> >> > >>> >> >> > >>>> But is there some technical reason why it's helpful for ASM >> proxies >> >> to >> >> > >>>> use >> >> > >>>> InvocationHandler specifically? Why wouldn't they just use >> Invoker >> >> > >>>> directly? >> >> > >>>> >> >> > >>>> Matt >> >> > >>>> >> >> > >>>> >> >> > >>>> On Thu, Aug 1, 2013 at 8:51 AM, Romain Manni-Bucau < >> >> > >>>> rmannibu...@gmail.com>wrote: >> >> > >>>> >> >> > >>>> > +1 >> >> > >>>> > >> >> > >>>> > jdkproxyfactory can even be hardcoded as a default IMO (without >> >> > using >> >> > >>>> the >> >> > >>>> > SPI) >> >> > >>>> > >> >> > >>>> > >> >> > >>>> > *Romain Manni-Bucau* >> >> > >>>> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >> >> > >>>> > *Blog: **http://rmannibucau.wordpress.com/*< >> >> > >>>> > http://rmannibucau.wordpress.com/> >> >> > >>>> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >> >> > >>>> > *Github: https://github.com/rmannibucau* >> >> > >>>> > >> >> > >>>> > >> >> > >>>> > >> >> > >>>> > 2013/8/1 James Carman <ja...@carmanconsulting.com> >> >> > >>>> > >> >> > >>>> > > You mean all the InvocationHandler classes in JdkProxy? I >> guess >> >> > we >> >> > >>>> > > could break those out into top-level classes, but then you'd >> >> have >> >> > >>>> > > multiple implementations on your classpath if you made a >> >> > dependency >> >> > >>>> on >> >> > >>>> > > commons-proxy-jdk. We could move those to "core" I guess. >> >> > >>>> > > >> >> > >>>> > > On Thu, Aug 1, 2013 at 7:49 AM, Romain Manni-Bucau >> >> > >>>> > > <rmannibu...@gmail.com> wrote: >> >> > >>>> > > > Ok for all excepted last point (i was not clear i think). >> The >> >> > >>>> > > ProxyFactory >> >> > >>>> > > > impl using jdk proxy uses Invocationhandler like the asm >> >> > >>>> implementation >> >> > >>>> > > so >> >> > >>>> > > > it would be great to be able to share the handler classes >> >> > between >> >> > >>>> both >> >> > >>>> > > impl. >> >> > >>>> > > > >> >> > >>>> > > > *Romain Manni-Bucau* >> >> > >>>> > > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >> >> > >>>> > > > *Blog: **http://rmannibucau.wordpress.com/*< >> >> > >>>> > > http://rmannibucau.wordpress.com/> >> >> > >>>> > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >> >> > >>>> > > > *Github: https://github.com/rmannibucau* >> >> > >>>> > > > >> >> > >>>> > > > >> >> > >>>> > > > >> >> > >>>> > > > 2013/8/1 James Carman <ja...@carmanconsulting.com> >> >> > >>>> > > > >> >> > >>>> > > >> On Thu, Aug 1, 2013 at 2:44 AM, Romain Manni-Bucau >> >> > >>>> > > >> <rmannibu...@gmail.com> wrote: >> >> > >>>> > > >> > ok, >> >> > >>>> > > >> > >> >> > >>>> > > >> > here it is: https://gist.github.com/rmannibucau/6128964 >> >> > >>>> > > >> > >> >> > >>>> > > >> >> >> > >>>> > > >> Thanks! >> >> > >>>> > > >> >> >> > >>>> > > >> > >> >> > >>>> > > >> > 1) i didn't fully get the goal of stub module, any >> >> pointers? >> >> > >>>> > > >> >> >> > >>>> > > >> It provides features very similar to the mocking support >> in >> >> > >>>> libraries >> >> > >>>> > > >> like Mockito/EasyMock. Basically, you can "train" a >> proxy to >> >> > do >> >> > >>>> what >> >> > >>>> > > >> you want in certain situations. >> >> > >>>> > > >> >> >> > >>>> > > >> > 2) in ProxyFactory methods have this kind of signature >> >> > >>>> > > >> > >> >> > >>>> > > >> > <T> T createDelegatorProxy( ClassLoader classLoader, >> >> > >>>> > ObjectProvider<?> >> >> > >>>> > > >> > delegateProvider, >> >> > >>>> > > >> > Class<?>... >> >> > >>>> proxyClasses ); >> >> > >>>> > > >> > >> >> > >>>> > > >> > why <T>if ObjectProvider is not ObjectProvider<T> (same >> for >> >> > >>>> Object >> >> > >>>> > for >> >> > >>>> > > >> > others method). basically T isn't matched. >> >> > >>>> > > >> > >> >> > >>>> > > >> >> >> > >>>> > > >> I'll have to take a look. I believe the <T> is there for >> >> > >>>> "syntactic >> >> > >>>> > > >> sugar", since you can pass in any classes you want really. >> >> > >>>> Hopefully >> >> > >>>> > > >> the user won't do something stupid and they'll actually >> pass >> >> > >>>> Class<T> >> >> > >>>> > > >> as one of the proxyClasses when they're asking for a >> return >> >> > type >> >> > >>>> of >> >> > >>>> > > >> <T> back. Since you can have multiple proxy classes, the >> >> > >>>> > > >> ObjectProvider can't really match any one particular one >> (it >> >> > >>>> needs to >> >> > >>>> > > >> support all). >> >> > >>>> > > >> >> >> > >>>> > > >> > 3) the jdk implementation uses InvocationHandler for the >> >> > >>>> proxying, >> >> > >>>> > asm >> >> > >>>> > > >> > implementation has almost the same (i didn't check but i >> >> > started >> >> > >>>> > from >> >> > >>>> > > an >> >> > >>>> > > >> > exact copy), it would be great to get them in a common >> >> > module to >> >> > >>>> > > avoid to >> >> > >>>> > > >> > duplicate it >> >> > >>>> > > >> > >> >> > >>>> > > >> >> >> > >>>> > > >> We have our own interface for InvocationHander, it's >> called >> >> > >>>> Invoker. >> >> > >>>> > > >> Other libraries can be "adapted" to ours if you want to >> reuse >> >> > >>>> > > >> something. >> >> > >>>> > > >> >> >> > >>>> > > >> >> >> > >>>> >> >> --------------------------------------------------------------------- >> >> > >>>> > > >> To unsubscribe, e-mail: >> dev-unsubscr...@commons.apache.org >> >> > >>>> > > >> For additional commands, e-mail: >> dev-h...@commons.apache.org >> >> > >>>> > > >> >> >> > >>>> > > >> >> >> > >>>> > > >> >> > >>>> > > >> >> > --------------------------------------------------------------------- >> >> > >>>> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >> > >>>> > > For additional commands, e-mail: dev-h...@commons.apache.org >> >> > >>>> > > >> >> > >>>> > > >> >> > >>>> > >> >> > >>>> >> >> > >>> >> >> > >>> >> >> > >> >> > --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >> > For additional commands, e-mail: dev-h...@commons.apache.org >> >> > >> >> > >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org