commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <>
Subject RE: [HiveMind] HiveMind ideas
Date Thu, 04 Mar 2004 19:12:40 GMT

> The speed of the two will probably be comparable. The main 
> advantage of using
> CGLIB2 is that your code will be simpler, since you are 
> dealing against a normal
> Java API (comparable to java.lang.reflect.Proxy) instead of writing
> pseudo-bytecode in string literals as you do with Javassist. 
> Also, CGLIB will
> handle things like caching and debugging support that you'd 
> otherwise have to
> write yourself.

I switched from BCEL to Javassist in the Tapestry 3.0 alpha timeframe. Although I don't doubt
CGLIB has a better API, I found the Javassist approach hard to beat.  It isn't psuedo-bytecode
it's pseudo-Java.  Yes, you get the runtime penality of parsing that pseudo-Java into some
kind of
AST and then into bytecodes ... but it means that you can do all this runtime enhancement
having to deal with stacks and bytecodes and all that.

With JDK proxies, and the CGLib samples I've seen, you still have flow of control into a single
method that must use cascading if statements to determine what method was actually invoked

The only other approach I've seen that I liked was in, I believe AspectWerkx, where you provided
real compiled Java class and AspectWerkx would scavenge the bytecode out of it, treating the
as a bytecode template.

The sad reality is that there are SO MANY frameworks out there for any situation that there's
no way
to keep up, so I can easily be laboring under some misconceptions. Still, what I saw in the
docs at didn't persuade me.

Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message