commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hls...@comcast.net>
Subject RE: [HIVEMIND] Why Javassist?
Date Sat, 20 Sep 2003 11:07:49 GMT
Absolutely; if you look at the ServiceInterceptorFactory interface, there's no mention of Javassist
or the ClassFactory service. The implementations chose to do it this way; I think inside the
unit
tests, the Count service may still be implemented using proxies.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com

> -----Original Message-----
> From: James Carman [mailto:james@carmanconsulting.com] 
> Sent: Friday, September 19, 2003 6:56 PM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [HIVEMIND] Why Javassist?
> 
> 
> Since you stated on the website that HiveMind is "agnostic" 
> about how interceptors are implemented, is there a way to use 
> proxies rather than javassist?
> 
> -----Original Message-----
> From: Howard M. Lewis Ship [mailto:hlship@comcast.net] 
> Sent: Friday, September 19, 2003 6:45 PM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [HIVEMIND] Why Javassist?
> 
> Mostly, because of the improved speed.  Javassist code will 
> not use any runtime reflection; its pure java code no 
> different from what's generated by the java compiler, so 
> Hotspot can optimize it quite a bit.
> 
> Reflection is faster in JDK 1.4, but still slower than full-bore code.
> 
> http://www.freeroller.net/page/hlship/20030708
> 
> I saw improvements of at least 5x using Javassist vs. JDK 
> proxies.  Since then, I've optimized the interceptors even 
> more by leveraging the actual types of objects (i.e., using 
> invokevirtual rather than invokeinterface). Still, it may all 
> disappear into the noise of a real application (that hits a 
> database, or an EJB via RMI).
> 
> Finally, by using Javassist, I could implement toString() 
> sensibly in the fabricated interceptor or proxy, which is 
> very, very useful when debugging (since there's no source to 
> step into for fabricated classes).
> 
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components 
> http://jakarta.apache.org/tapestry
> http://jakarta.apache.org/commons/sandbox/hivemind/
> http://javatapestry.blogspot.com
> 
> > -----Original Message-----
> > From: James Carman [mailto:james@carmanconsulting.com]
> > Sent: Friday, September 19, 2003 6:38 PM
> > To: commons-dev@jakarta.apache.org
> > Subject: [HIVEMIND] Why Javassist?
> > 
> > 
> > What is the benefit of using Javassist rather than just using
> > dynamic proxies?  Consider the following code.
> > 
> > public interface Interceptor
> > { 
> >   public Object intercept( Method method, Object[] args,
> > InterceptorChain chain ) throws Throwable; }
> > 
> > public interface InterceptorChain
> > {
> >   public Object intercept( Method method, Object[] args )
> > throws Throwable; }
> > 
> > If HiveMind used this approach (similar to how I structured
> > it in my article at JavaWorld), all interceptor logic could 
> > be coded in straight Java code, rather than using javassist 
> > to add logic to the invocation.  Consider the following 
> interceptor...
> > 
> > public class LoggingInterceptor implements Interceptor
> > {
> >   private Log log = LogFactory.getLog( getClass() );
> >   public Object intercept( Method method, Object[] args,
> > InterceptorChain chain ) throws Throwable
> >   {
> >     log.debug( "Entering " + method );
> >     chain.intercept( method, args );
> >     log.debug( "Leaving " + method );
> >   }
> > }
> > 
> > Now, this is a trivial example, but you can see that the
> > potential is there for a more robust implementation.  Maybe 
> > I'm just not understanding the framework correctly, but I 
> > don't see how javassist buys us much and it adds a TREMENDOUS 
> > complexity!  This code is MUCH simpler than the 
> > LoggingInterceptorFactory class!  An added bonus, we can rely 
> > upon the COMPILER rather than waiting until runtime to find a typo. 
> > 
> > 
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > 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
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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