Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade to ASM 4.0 and CGLIB 3.0 [SPR-9669] #14303

spring-projects-issues opened this issue Aug 7, 2012 · 1 comment

Upgrade to ASM 4.0 and CGLIB 3.0 [SPR-9669] #14303

spring-projects-issues opened this issue Aug 7, 2012 · 1 comment
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement


Copy link

spring-projects-issues commented Aug 7, 2012

Chris Beams opened SPR-9669 and commented

ASM 4.0 was released in Oct 2011 to address Java 7 bytecode compatibility, particularly with regard to invokedynamic 1.

Certain public API changes were made in the process. Upgrade Spring's own internal repackaging of ASM to ensure users don't run into problems with Java 7 classes. This is most likely to cause problems in conjunction with Spring's component-scanning functionality, so this is high priority.

The repackaged org.springframework.asm classes are currently based on ASM 2.2.3, which is now several generations behind. Here are the differences between APIs across those generations:

2.2.3-> 3.2:
3.2 -> 3.3:
3.3 -> 3.4:

CGLIB 3.0 was released on May 25th, 2012 2 in order to upgrade its dependency on ASM to 4.0. This also involved some API changes. Upgrade Spring's dependency on CGLIB (currently at 2.2) to 3.0. Impact may or may not be significant, but should not have external impact at the API level (because we do not expose CGLIB APIs). It will be important to advise users as to whether CGLIB 3.0 is the new lower bound supported by Spring as of 3.2 GA, or if 2.2 is still supported (with caveats about Java 7 support). This depends again on the extent of internal API changes necessary to support the upgrade.

Issue Links:

Copy link
Collaborator Author

Chris Beams commented

commit 92500ab9023ae2afd096be9c014423fcd4180c55
Author: Chris Beams <>
Commit: Chris Beams <>

    Upgrade to CGLIB 3 and inline into spring-core
    CGLIB 3 has been released in order to depend on ASM 4, which Spring now
    depends on internally (see previous commit).
    This commit eliminates spring-beans' optional dependency on cglib-nodep
    v2.2 and instead repackages net.sf.cglib => org.springframework.cglib
    much in the same way we have historically done with ASM.
    This change is beneficial to users in several ways:
     - Eliminates the need to manually add CGLIB to the application
       classpath; especially important for the growing number of
       @Configuration class users. Java-based configuration functionality,
       along with proxy-target-class and method injection features now
       work 'out of the box' in Spring 3.2.
     - Eliminates the possibility of conflicts with other libraries that
       may dependend on differing versions of CGLIB, e.g. Hibernate and its dependency on CGLIB 2.1.3 would easily cause a
       conflict if the application were depending on CGLIB 3 for
       Spring-related purposes.
     - Picks up CGLIB 3's changes to support ASM 4, meaning that CGLIB is
       that much less likely to work well in a Java 7 environment due to
       ASM 4's support for transforming classes with invokedynamic
       bytecode instructions.
    On CGLIB and ASM:
      CGLIB's own dependency on ASM is also transformed along the way to
      depend on Spring's repackaged org.springframework.asm, primarily to
      eliminate unnecessary duplication of ASM classfiles in spring-core and
      in the process save around 100K in the final spring-core JAR file size.
      It is coincidental that spring-core and CGLIB currently depend on the
      exact same version of ASM (4.0), but it is also unlikely to change any
      time soon. If this change does occur and versions of ASM drift, then
      the size optimization mentioned above will have to be abandoned. This
      would have no compatibility impact, however, so this is a reasonable
      solution now and for the forseeable future.
    On a mysterious NoClassDefFoundError:
      During the upgrade to CGLIB 3.0, Spring test cases began failing due to
      NoClassDefFoundErrors being thrown from CGLIB's DebuggingClassWriter
      regarding its use of asm-util's TraceClassVisitor type. previous
      versions of cglib-nodep, particularly 2.2, did not cause this behavior,
      even though cglib-nodep has never actually repackaged and bundled
      asm-util classes. The reason for these NoClassDefFoundErrors occurring
      now is still not fully understood, but appears to be due to subtle JVM
      bytecode preverification rules. The hypothesis is that due to minor
      changes in DebuggingClassWriter such as additional casts, access to
      instance variables declared in the superclass, and indeed a change in
      the superclass hierarchy, preverification may be kicking in on the
      toByteArray method body, at which point the reference to the missing
      TraceClassVisitor type is noticed and the NCDFE is thrown. For this
      reason, a dummy implementation of TraceClassVisitor has been added to
      spring-core in the org.springframework.asm.util package. This class
      simply ensures that Spring's own tests never result in the NCDFE
      described above, and more importantly that Spring's users never
      encounter the same.
    Other changes include:
     - rename package-private Cglib2AopProxy => CglibAopProxy
     - eliminate all 'cglibAvailable' checks, warnings and errors
     - eliminate all 'CGLIB2' language in favor of 'CGLIB'
     - eliminate all mention in reference and java docs of needing to add
       cglib(-nodep) to one's application classpath
    Issue: SPR-9669
commit c16f18a5fd659f34d6290b5f2cffe54534b7592a
Author: Chris Beams <>
Commit: Chris Beams <>

    Remove spring-asm and inline ASM 4 into spring-core
    ASM 4.0 is generally compatibile with Java 7 classfiles, particularly
    including 'invokedynamic' instructions. This is important when
    considering that Spring's component-scanning support is internally
    ASM-based and it is increasingly likely that component classes having
    invokedynamic instructions may be encountered and read by ASM.
    This upgrade, then, is primarily preventive in nature.
    Changes include:
     - upgrade from ASM 2.2.3 to ASM 4.0
     - adapt to ASM API changes as necessary throughout spring-core,
       resulting in no impact to the public Spring API.
     - remove dedicated spring-asm module
     - use new :spring-core:asmRepackJar task to repackage
       org.objectweb.asm => org.springframework.asm as per usual and write
       repackaged classes directly into spring-core jar
    The choice to eliminate the spring-asm module altogether and instead
    inline the repackaged classes directly into spring-core is first to
    eliminate an otherwise unnecessary second jar. spring-core has a
    non-optional dependency on spring-asm meaning it is always on the
    application classpath. This change simplifies that situation by
    consoliding two jars into one. The second reason for this choice is in
    anticipation of upgrading CGLIB to version 3 and inlining it into
    spring-core as well. See subsequent commit for details.
    Issue: SPR-9669
commit 69a392981e135a1c78ed18b9495626e7b34349e4
Author: Chris Beams <>
Commit: Chris Beams <>

    Upgrade JarJar to version 1.3
    JarJar 1.3 now uses ASM 4 in order to be compatible with Java 7
    'invokedynamic' instructions. This is not an immediate concern for
    the classes that we use JarJar to repackage and transform, but is a
    timely upgrade in anticipation of the subsequent commits in which we
    upgrade Spring's own dependency on ASM from 2.2.3 to 4.0 and Spring's
    dependency on CGLIB from 2.2 to 3.0 (which in turn depends on ASM 4.0).
    Issue: SPR-9669

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
None yet

No branches or pull requests

1 participant