commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject RE: [HIVEMIND] Why Javassist?
Date Fri, 19 Sep 2003 22:56:08 GMT
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




Mime
View raw message