CGLib (Code Generation Library) is used to generate Java byte code at runtime. It sits on top of ASM, and is used by various open source tools out there. A beta for CGLib 2 has been released, with a new code generation API. A fast reflection implementation and code transformation API for JDO-style class enhancement was added, which really helps folks like Hibernate and XORM.

New Features

1. Enhancer uses more callback interfaces for optimizations.
2. BulkBean and reflect package replaces MetaClass, it produces more readable error messages, and optimizations.
  3. Code transformation API was requested by CGLib users ( XORM and Hibernate ),
     It has all features to implement build or load time JDO enhancer:

     FieldProvider transformation implements interface to read/write field values.
     InterceptField transformation replaces GET/PUT FIELD instuctions with methods to intercept field value changes.
     Delegate transformation adds interfaces to class and delegates to generic implementation.
     ClassInit transforms static initializer to register class.
     Base classes for custom class loader and abstract ant task.

Find more about CGLib at
http://cglib.sourceforge.net

Cglib2 sits on top of ASM http://asm.objectweb.org, it is small and fast Java bytecode manipulation library.
Internal bytecode manipulation "abstraction" was removed, but cglib 1.x will continue to support both libraries.

There used to be two versions of CGLib - one that used BCEL and another that used ASM. I'm not aware of any reason to use the BCEL version, unless your project is already using BCEL. Is CGLib giving up on BCEL?

Shoot.. I need to read better.

Hi all-,
Are there plans to integrate CGLIB with JFluid (http://research.sun.com/projects/jfluid/). It looks like Sun is implementing some standard way of dynamic byte-code instrumentation.

> Are there plans to integrate CGLIB with JFluid (http://research.sun.com/projects/jfluid/). It looks like Sun is implementing some standard way of dynamic byte-code instrumentation.

The are no problems if community needs it.

It looks like Sun is implementing some standard way of dynamic byte-code instrumentation.

How ironic that Sun would publicize how to manipulate bytecode but offer no help at programaticly inspecting Java source code. Presumably developers still care about source code.

[i]offer no help at programaticly inspecting Java source code[/i]

They do - It's called JavaCC. You can get a Java grammar for it very easily.

Frankly, though, I don't understand why you would _prefer_ working on Java source code. When I work with bytecode, I'm essentially working with the AST that the lexer/parser and associated semantic analysis code has already built for me. Why duplicate that step? I can also work with classes for which I don't have the source code. In the case of JFluid, that is particularly important, as you'd like to be able to examine any hotspots that occur _outside_ of your own code.

On the other hand, I thought it would be quite cool if the Java compiler was capable of running semantics plugins. Essentially, the front-end parser wouldn't change (which means that the language would remain stable), but you could plug in your own transformer that could read the generated AST (along with the user metadata from 175) and perform any transformations on it that floats your boat.

Now, that, could be very useful.

God bless,
-Toby Reyelts

My understanding is that this helps the hibernate startup time dramatically, when compared to the older cglib versions. I haven't tried this myself yet, but when you have a lot of classes mapped, hibernate can take a while to get moving. I believe the cglib-asm version helps quite a bit.

It must be better to dissable reflection optimizer (MetaClass) at development time, I think we will merge cglib and cglib2 reflection implementation, cglib 1.0 reflection must be faster at runtime, but it is too agresive (it generates a lot of classes and uses a lot of memory for cache)

I use Javassist with Tapestry and HiveMind because it is so simple to use; you feed it stuff that looks like Java statements and it parses it and does the bytecode mods (also, the Javassist library is smaller than BCEL!). This saves me the trouble of dealing with bytecode myself ... big productivity gain for me. Does CGLib have comparable features or are they planned?

Howard, CGLIB and Javassist really do two quite different things. They don't compete at all. Use Javassist if you want to pass actual Java code and compile it. Use CGLIB if you are just looking for a library of simple solutions for common problems. I think of it as a (much richer and, perhaps, facter) replacement for JDK reflection package.

cheers

P.S. CGLIB is fantastic ;-)

From the website: "cglib is a powerful, high performance and quality Code Generation Library, It is used to extend JAVA classes and implements interfaces at runtime".

That's exactly what I use Javassist to do so I can't see how these two frameworks are unrelated. Javassist just adds a cool layer of converting Java-like syntax into bytecode for you.

>
> That's exactly what I use Javassist to do so I can't see how these two frameworks are unrelated. Javassist just adds a cool layer of converting Java-like syntax into bytecode for you.

I like Javassist too.

> >
> > That's exactly what I use Javassist to do so I can't see how these two frameworks are unrelated. Javassist just adds a cool layer of converting Java-like syntax into bytecode for you.
>
> I like Javassist too.

BTW scripting languages are very good (simple to use) for dynamic code generation, rhino can compile script to JAVA byte code. It is a very powerfull technology too.

http://jakarta.apache.org/bsf/resources.html

> compete at all. Use Javassist if you want to pass actual Java code and
> compile it. Use CGLIB if you are just looking for a library of simple
> solutions for common problems. I think of it as a (much richer and, perhaps,
> facter) replacement for JDK reflection package.

While this was definitely true of CGLIB 1.0, the transformation API in CGLIB2 does overlap with Javassist somewhat. The main difference is that in CGLIB all transformations are coded at the bytecode level (using an "assembly"-like API), whereas Javassist has a compiler built-in that derives the bytecode from actual Java source (well, almost actual source). I think it is kind of cool and have thought about hooking the Javassist compiler into CGLIB as an alternative frontend. But for some things you really need to get down to the bytecode.

It is true, though, that the main thrust is still to provide a library of utilities that use code generation/transformation under the hood but have a simple API. If anyone actually uses the low level API, that probably means we need another utility in CGLIB! In Howard's case I'm pretty sure the Enhancer class + LazyLoader interceptor would suffice, please join the list if you are interested.

BTW CGLIB2 also uses the Aspectwerkz 0.8 "online mode" hook library to allow for runtime transformations, in addition to Ant-based offline transformation.

BTW CGLIB now uses ASM instead of BCEL, and CGLIB+ASM is smaller than Javassist by a little bit. Depending on your requirements, you might be able to use the existing CGLIB utils and avoid doing the bytecode modifications yourself. If not, Javassist is a good choice if you don't want to learn bytecode.

Looking forward to checking it out. It's become a very important tool behind the scenes in several frameworks.

Regards,
Rod

Chris Nokleberg's talks about "Optimizing XML parsing with code generation" in his blog, which features good ole CGLib:

http://sixlegs.com/blog/java/optimizing-xml-parsing.html

I'm implementing a new AOP framework using CGLIB 2 and it's really working great. Nice API's and it's very fast. Especially the reflection substitution stuff is a welcome thing to have.

Great job guys!

It is possible to implement reflection with all features like "setAccessible" using class file transformations, but it will use more memory than native reflection.
Native methods are "slow", but pure JAVA implementation will not be much "faster" with security. It is possible to ignore JAVA security for performance in the most of use cases like server applications ( I do not think somebody is going to download and run "untrusted" code on server ).

First af all, CGLIB is great!

But I found that CGLIB 2 beta 1 is somewhat slower then CGLIB 1.0.
For example, CGLIB 1.0 reflective method invocation is only about two times slower then direct method invocation of non-static and non-final method. This is great result, I must admint. CGLIB 2.0 beta 1 reflective method invocation is three times slower the direct invocation, thus 2.0 b1 is about 33% slower then 1.0 in reflective method invocation.

Also, I found that calling intercepted method with CGLIB 1.0 is about 7 times slower then calling method of the original non-enhanced class. That is a good result (but not as good as for reflective invocation!). Calling interceped method with CGLIB 2.0 b1 is about 9 times slower, thus CGLIB 2 method interception is about 20% slower then CGLIB 1.

I hope CGLIB 2 will be more optimized for final release!

Best regards,
Mileta

Mileta,

Could you post your performance benchmark code (even if it is not in polished state)? I was think of building a cglib performance benchmark suite, and it would be nice to start with some existing code.

Thanks.

George Zou

http://www.alphaworks.ibm.com/tech/jikesbt

http://asm.objectweb.org/

http://jakarta.apache.org/bcel/

http://opensource.nailabs.com/jbet/

http://www.jboss.org/developers/projects/javassist.html

http://www.ej-technologies.com/products/jclasslib/overview.html

http://serp.sourceforge.net/