What's the difference between Spring CGLIB and CGLIB?

Question

Spring doesn't contains cglib dependency, both cglib and spring cglib has the Enhancer class, one is net.sf.cglib.proxy.Enhancer while the another is org.springframework.cglib.proxy, what's the difference between them?

Answer 1

This is called repackaging: instead of using some library as a dependency, a project makes a copy of the dependency as part of their own project and places it in a different package.

The reason for doing this is that a project using Spring might want to use cglib itself. If Spring had a particular version of cglib as a dependency, it would be impossible for the project using Spring to pick a different version. But if Spring uses repackaged cglib which is in a different package, there is no version conflict and the project can use any version of cglib if they like.

Some projects repackage Guava, Netty or other popular libraries in a similar manner.

Answer 2

Spring shipped with repackaged cglib. You can see actual cglib version in Gradle buildfile. Search for word "cglib" and you find it:

// As of Spring 4.0.3, spring-core includes asm 5.x and repackages cglib 3.2, inlining
// both into the spring-core jar. cglib 3.2 itself depends on asm 5.x and is therefore
// further transformed by the JarJar task to depend on org.springframework.asm; this
// avoids including two different copies of asm unnecessarily.
def cglibVersion = "3.2.4"

Answer 3

Cglib was inlined into Spring as of version 3.2.0 as it is mentioned in the release notes of this version:

In prior versions, users of Spring's subclass-based AOP proxies (e.g. via proxy-target-class="true") and @Configuration class support were required to declare an explicit dependency on CGLIB 2.2. As of Spring Framework 3.2, we now repackage and inline the newly-released CGLIB 3.0.

This means greater convenience for users, as well as correct functionality for Java 7 users who are creating subclass proxies of types that contain invokedynamic bytecode instructions. Repackaging CGLIB internally ensures no classpath conflicts with other third party frameworks that may depend on other versions of CGLIB.

This was done to provide automatic updates that correlate with cglib and avoiding of version conflicts as cglib somestimes breaks its API.

Answer 4

No difference, just a repackaging

---

ps. class ObjenesisCglibAopProxy extends CglibAopProxy

Objenesis aims to overcome these restrictions by bypassing the constructor on object instantiation.