• C
    Upgrade to CGLIB 3 and inline into spring-core · 92500ab9
    Chris Beams 提交于
    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
       3.3.1.ga 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
    92500ab9
beans-scopes.xml 33.9 KB