What is the difference between Spring CGLIB and CGLIB?

Question

Spring does not contain cglib dependencies, cglib and spring cglib has an Enhancer class, one is net.sf.cglib.proxy.Enhancer and the other is org.springframework.cglib.proxy , what's the difference between them?

Answer 1

This is called repackaging: instead of using any library as a dependency, the project creates a copy of the dependency as part of its own project and puts it in another package.

The reason for this is that a project using Spring might want to use cglib itself. If Spring has a specific version of cglib as a dependency, a project using Spring will not be able to select a different version. But if Spring uses the repackaged cglib, which is in another package, there is no version conflict, and the project can use any version of cglib if they want.

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

Answer 2

Spring comes with a repackaged cglib. You can see the actual version of cglib in the Gradle buildfile . Find the word "cglib" and you will 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 has been wrapped in Spring since version 3.2.0, as mentioned in the release notes for this version :

In previous versions, Spring users of the AOP proxy subclass (for example, through proxy-target-class = "true") and support for the @Configuration class were required to declare an explicit dependency on CGLIB 2.2. Starting with SpringFramework 3.2, we are now repackaging and installing the recently released CGLIB 3.0.

This means greater user friendliness as well as proper functionality for Java 7 users who subclass proxy types containing invokedynamic bytecode instructions. CGLIB packaging change internally ensures that there are no class conflicts with other third-party classes that may depend on other versions of CGLIB.

This was done to provide automatic updates that correlate with cglib and avoid version conflicts, since cglib somestimes violates its API.