> 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 that 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 without 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 originally. The only other approach I've seen that I liked was in, I believe AspectWerkx, where you provided a real compiled Java class and AspectWerkx would scavenge the bytecode out of it, treating the class 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 cglib.sf.net didn't persuade me. -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Tapestry: Java Web Components http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
