JFTR: in Apache OpenWebBeans we switched to ASM because Javassist caused too much mem leaks and hassles.
But we do only use reflection when it's really needed. Means methods which are neither delegated nor intercepted will delegated via native java calls. The same happens for 'NormalScoped' proxies (a CDI specialty) which only use pure java code and no reflection. That said, a few figures: 10 million invocations on the proxies we generate using ASM (which do the getInstance() internally as well -> ThreadLocal, Map lookup, etc) take 30ms on my notebook. LieGrue, strub ----- Original Message ----- > From: Romain Manni-Bucau <rmannibu...@gmail.com> > To: Commons Developers List <dev@commons.apache.org> > Cc: > Sent: Thursday, 1 August 2013, 17:15 > Subject: Re: [proxy] and impl > > 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
