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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
