commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: [proxy] and impl
Date Thu, 01 Aug 2013 15:15:53 GMT
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 <james@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
> <rmannibucau@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 <gudnabrsam@gmail.com>
> >
> >> That's my point; it doesn't.
> >>
> >>
> >> On Thu, Aug 1, 2013 at 9:49 AM, James Carman <
> james@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
> >> > <rmannibucau@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 <gudnabrsam@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" <
> rmannibucau@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 <gudnabrsam@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 <
> >> > >>>> rmannibucau@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 <james@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
> >> > >>>> > > <rmannibucau@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 <james@carmanconsulting.com>
> >> > >>>> > > >
> >> > >>>> > > >> On Thu, Aug 1, 2013 at 2:44 AM, Romain
Manni-Bucau
> >> > >>>> > > >> <rmannibucau@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-unsubscribe@commons.apache.org
> >> > >>>> > > >> For additional commands, e-mail:
> dev-help@commons.apache.org
> >> > >>>> > > >>
> >> > >>>> > > >>
> >> > >>>> > >
> >> > >>>> > >
> >> > ---------------------------------------------------------------------
> >> > >>>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> > >>>> > > For additional commands, e-mail: dev-help@commons.apache.org
> >> > >>>> > >
> >> > >>>> > >
> >> > >>>> >
> >> > >>>>
> >> > >>>
> >> > >>>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> > For additional commands, e-mail: dev-help@commons.apache.org
> >> >
> >> >
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message