commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject RE: [proxy] vs proxytoys
Date Wed, 24 Aug 2005 23:09:09 GMT
Jörg,

Out of curiosity, what is the (real-life) use case where you would actually
have a proxy object which doesn't delegate to some implementation?  I'm not
saying there isn't one.  I may very well be just too ignorant to come up
with one on my own. :-)  I can be quite narrow-minded at times.

However, we could support a similar concept in commons-proxy by just using a
MethodInterceptor and not actually calling MethodInvocation.proceed().  That
way, it would never really get to the target object.  We could create a
NullProvider (actually I just did it) which always returns null (extended
ConstantProvider) and could be the target for that type of proxy.  

James

-----Original Message-----
From: Jörg Schaible [mailto:joerg.schaible@gmx.de] 
Sent: Wednesday, August 24, 2005 6:49 PM
To: James Carman
Cc: 'Jakarta Commons Developers List'
Subject: Re: [proxy] vs proxytoys

On Wednesday 24 August 2005 23:32, James Carman wrote:
JC> To be quite honest, nobody has fully provided the JavassistProxyFactory
JC> implementation to commons-proxy yet, either. :-)  I started on it but
JC> couldn't get the intercepted proxies working.  

:))

JC> One key difference, it seems, between proxytoys and commons-proxy is
that
JC> commons-proxy somewhat assumes that there will be a "target" object
(some
JC> actual object that implements the core functionality) to the invocation.
JC> ProxyToys doesn't seem to make that assumption (correct me if I'm
wrong).

Right. Some view toy proxies can act without a target.

JC> One problem that I see with ProxyToys is in the implementation of the
JC> DelegatingInvoker and SimpleInvoker (what I would have to use if I did 
have
JC> a target object) class.  No matter what ProxyFactory you're using,
JC> DelegatingInvoker and SimpleInvoker ultimately use JDK reflection to 
invoke
JC> the method on the delegate/target.

Yes. In the end it the proxy uses always InvocationHandler.invoke() as 
callback.

JC> Commons-proxy doesn't do that.  

Must have a look at the code :)

JC> ProxyToys, ultimately, should be much
JC> slower, which is illustrated by the following code:
JC> 
JC> public class CompareToProxyToys
JC> {
JC>     private static final int N = 100000000;
JC> 
JC>     public static void main( String[] args )
JC>     {
JC>         final EchoImpl impl = new EchoImpl();
JC>         final Echo proxyToys = ( Echo )new
JC> com.thoughtworks.proxy.factory.CglibProxyFactory().createProxy( new 
Class[]
JC> { Echo.class }, new SimpleInvoker( impl ) );
JC>         final Echo commonsProxy = ( Echo )new
JC> CglibProxyFactory().createProxy( new ConstantProvider<Echo>( impl ),
JC> Echo.class );
JC>         System.out.println( MessageFormat.format( "Average duration of
JC> ProxyToys is approximately {0,number,0.00#} times slower than
JC> commons-proxy.", new Double( averageDuration( proxyToys ) /
JC> averageDuration(commonsProxy ) ) ) );
JC>     }
JC> 
JC>     private static double averageDuration( Echo echo )
JC>     {
JC>         final long before = System.nanoTime();
JC>         for( int i= 0; i < N; ++i )
JC>         {
JC>             echo.echoBack( "Hello, World!" );
JC>         }
JC>         final long after = System.nanoTime();
JC>         return ( ( after - before ) * 1.0 / N );
JC>     }
JC> }
JC> 
JC> ProxyToys' average duration was approximately 7x slower than
commons-proxy
JC> using this crude test (I'm not saying these are the best metrics in the
JC> world).

I'll investigate.

JC> Again, I allowed both implementations to use a CGLIB-based proxy.

Well, no <g>

The CglibProxyFactory of ProxyToys will use internally a JDK proxy if the 
proxy implements exactly one interface. Don't ask me why, that is not my 
code. But I'll try this without that "optimization".

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message