Details

    • Last commented by a User:
      false

      Description

      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: http://asm.ow2.org/jdiff223to32/changes.html
      3.2 -> 3.3: http://asm.ow2.org/jdiff32to33/changes.html
      3.3 -> 3.4: http://asm.ow2.org/jdiff33to40/changes.html

      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.

      [1]: http://mail.ow2.org/wws/arc/asm/2011-10/msg00025.html
      [2]: http://cglib.cvs.sourceforge.net/viewvc/cglib/cglib/build.xml?revision=1.56&view=markup

        Issue Links

          Activity

          Hide
          Chris Beams added a comment - - edited
          commit 92500ab9023ae2afd096be9c014423fcd4180c55
          Author: Chris Beams <cbeams@vmware.com>
          Commit: Chris Beams <cbeams@vmware.com>
          
              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
                 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
          
          commit c16f18a5fd659f34d6290b5f2cffe54534b7592a
          Author: Chris Beams <cbeams@vmware.com>
          Commit: Chris Beams <cbeams@vmware.com>
          
              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 <cbeams@vmware.com>
          Commit: Chris Beams <cbeams@vmware.com>
          
              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).
              
              See https://code.google.com/p/jarjar/wiki/ChangeLog
              
              Issue: SPR-9669
          
          Show
          Chris Beams added a comment - - edited commit 92500ab9023ae2afd096be9c014423fcd4180c55 Author: Chris Beams <cbeams@vmware.com> Commit: Chris Beams <cbeams@vmware.com> 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 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 commit c16f18a5fd659f34d6290b5f2cffe54534b7592a Author: Chris Beams <cbeams@vmware.com> Commit: Chris Beams <cbeams@vmware.com> 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 <cbeams@vmware.com> Commit: Chris Beams <cbeams@vmware.com> 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). See https://code.google.com/p/jarjar/wiki/ChangeLog Issue: SPR-9669

            People

            • Assignee:
              Chris Beams
              Reporter:
              Chris Beams
              Last updater:
              Chris Beams
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                1 year, 35 weeks, 5 days ago

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - Not Specified
                Not Specified
                Logged:
                Time Spent - 2.5d
                2.5d