Uploaded image for project: 'Spring Framework'
  1. Spring Framework
  2. SPR-11656

Basic Java 8 bytecode compatibility for Spring 3.2.x through ASM 5.0.2

    Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Critical
    • Resolution: Complete
    • Affects Version/s: 3.2.8
    • Fix Version/s: 3.2.9
    • Component/s: Core

      Description

      The current version of ASM (v 4) makes Spring @ComponentScan and other ASM reliant features unusable when running on Java 8.

      Pull request 510 upgrades ASM to 5.0.0 (should be 5.0.1). According to the ASM release notes this version should still be backwards compatible with Java 5, 6, 7 and 8.

      This is a major obstacle at least for those using Camel as it is not Spring 4 compatible.

        Issue Links

          Activity

          Hide
          mbknor Morten Kjetland added a comment -

          Here is a somewhat related issue over in Camel-land: https://issues.apache.org/jira/browse/CAMEL-7074

          Show
          mbknor Morten Kjetland added a comment - Here is a somewhat related issue over in Camel-land: https://issues.apache.org/jira/browse/CAMEL-7074
          Hide
          juergen.hoeller Juergen Hoeller added a comment -

          Even if we originally meant to only do Java 8 bytecode compatibility in the Spring 4.x line, I'm open to reconsideration at this point: ASM 5.0.1 is out and used in Spring Framework 4.0.3 already, so with some real-life validation of that combination, we could arguably use it in 3.2.9 as well.

          That said, the 3.2.9 release might happen as late as June, since it probably won't go along with 4.0.4 but rather with 4.0.5...

          Juergen

          Show
          juergen.hoeller Juergen Hoeller added a comment - Even if we originally meant to only do Java 8 bytecode compatibility in the Spring 4.x line, I'm open to reconsideration at this point: ASM 5.0.1 is out and used in Spring Framework 4.0.3 already, so with some real-life validation of that combination, we could arguably use it in 3.2.9 as well. That said, the 3.2.9 release might happen as late as June, since it probably won't go along with 4.0.4 but rather with 4.0.5... Juergen
          Hide
          juergen.hoeller Juergen Hoeller added a comment -

          Two notes on the limitations of Java 8 support in the 3.2.x line:

          • Spring Framework 3.2.x is based on unpatched repackaged versions of ASM and CGLIB. At this point, that's planned to be ASM 5.0.1 and CGLIB 3.1 for Spring 3.2.9, providing basic Java 8 bytecode compatibility. However, for Spring Framework 4's locally forked version of ASM, there's already a patch beyond ASM 5.0.1 as well as additional CGLIB 3.1 compatibility patches for the "-parameters" compiler flag, all scheduled to go into Spring Framework 4.0.4... So if there are any issues with Java 8 bytecode handling, in particular in combination with the "-parameters" flag, we urge you to upgrade to Spring Framework 4.0.4+. This won't be addressed in 3.2.9 since we're not going to introduce a local ASM fork there anymore.
          • Spring Framework 3.2.x uses AspectJ 1.7.4. For full Java 8 support in AspectJ, you'll have to use AspectJ 1.8. We're only officially supporting AspectJ 1.8 final in Spring Framework 4.0.4+... Even if it is likely to work with Spring Framework 3.2.x as well, we're not officially supporting it.

          All in all, Java 8 support in Spring Framework 3.2.9 will just be "best effort" in terms of accepting the Java 8 bytecode level. For comprehensive Java 8 support, go Spring 4+.

          Juergen

          Show
          juergen.hoeller Juergen Hoeller added a comment - Two notes on the limitations of Java 8 support in the 3.2.x line: Spring Framework 3.2.x is based on unpatched repackaged versions of ASM and CGLIB. At this point, that's planned to be ASM 5.0.1 and CGLIB 3.1 for Spring 3.2.9, providing basic Java 8 bytecode compatibility. However, for Spring Framework 4's locally forked version of ASM, there's already a patch beyond ASM 5.0.1 as well as additional CGLIB 3.1 compatibility patches for the "-parameters" compiler flag, all scheduled to go into Spring Framework 4.0.4... So if there are any issues with Java 8 bytecode handling, in particular in combination with the "-parameters" flag, we urge you to upgrade to Spring Framework 4.0.4+. This won't be addressed in 3.2.9 since we're not going to introduce a local ASM fork there anymore. Spring Framework 3.2.x uses AspectJ 1.7.4. For full Java 8 support in AspectJ, you'll have to use AspectJ 1.8. We're only officially supporting AspectJ 1.8 final in Spring Framework 4.0.4+... Even if it is likely to work with Spring Framework 3.2.x as well, we're not officially supporting it. All in all, Java 8 support in Spring Framework 3.2.9 will just be "best effort" in terms of accepting the Java 8 bytecode level. For comprehensive Java 8 support, go Spring 4+. Juergen
          Hide
          juergen.hoeller Juergen Hoeller added a comment -

          It's also worth noting that the ASM 5.0.1 upgrade delivers a few fixes for compatibility with recent JDK 7 versions, avoiding VerifyErrors for specific cases when generating classes.

          From that perspective, the ASM 5 upgrade (which requires the CGLIB 3.1 upgrade since CGLIB 3.0 only works with ASM 4.0 strictly) is worth it for 3.2.9 aside from Java 8 bytecode compatibility as well. In fact, Spring up until 3.2.8 included the original ASM 4.0 release (because of CGLIB 3.0 as noted above, with CGLIB 3.1 only having appeared in December 2013), so this upgrade brings all the fixes of last year's ASM 4.1 and 4.2 releases as well.

          Juergen

          Show
          juergen.hoeller Juergen Hoeller added a comment - It's also worth noting that the ASM 5.0.1 upgrade delivers a few fixes for compatibility with recent JDK 7 versions, avoiding VerifyErrors for specific cases when generating classes. From that perspective, the ASM 5 upgrade (which requires the CGLIB 3.1 upgrade since CGLIB 3.0 only works with ASM 4.0 strictly) is worth it for 3.2.9 aside from Java 8 bytecode compatibility as well. In fact, Spring up until 3.2.8 included the original ASM 4.0 release (because of CGLIB 3.0 as noted above, with CGLIB 3.1 only having appeared in December 2013), so this upgrade brings all the fixes of last year's ASM 4.1 and 4.2 releases as well. Juergen
          Hide
          juergen.hoeller Juergen Hoeller added a comment -

          We're going to use the just-released ASM 5.0.2 for Spring Framework 3.2.9 now (likely to be released next week).

          Juergen

          Show
          juergen.hoeller Juergen Hoeller added a comment - We're going to use the just-released ASM 5.0.2 for Spring Framework 3.2.9 now (likely to be released next week). Juergen
          Hide
          przemyslaw.wyszkowski@cern.ch Przemek Wyszkowski added a comment -

          Dear Juergen,

          First of all, let me apologize for the unfortunate placement of this post - it is not about the issue itself but it is relevant. If there is a more suitable place where this question could be posted - please let me know.

          Recently we have moved the development in our enterprise to Java 8 compiler with 1.7 target. We still depend on Spring 3.2.13 (which has already the ASM version 5.0.2 included). We're planning to move to Spring 4.1.6, however for now we are not able to proceed due to internal reasons (changes need to be made and released in a huge codebase which still relies on the old spring-beans.dtd, see SPR-12836). For the moment we are wondering if we can move with our development environment to 1.8 target and stay with Spring version 3.2.13. I was trying to investigate what could be the threads of such approach and what will not work after such change. I have done a couple of tests (introduced a couple of Java 8 features to the code) but for now it seems to me that everything works just fine (at least from the functionalities we use at the moment).

          Can you please explain what problems/limitations we may face if we move to 1.8 target without upgrading Spring version to 4?

          I would be grateful for your opinion on this topic.

          Cheers,
          Przemek

          Show
          przemyslaw.wyszkowski@cern.ch Przemek Wyszkowski added a comment - Dear Juergen, First of all, let me apologize for the unfortunate placement of this post - it is not about the issue itself but it is relevant. If there is a more suitable place where this question could be posted - please let me know. Recently we have moved the development in our enterprise to Java 8 compiler with 1.7 target. We still depend on Spring 3.2.13 (which has already the ASM version 5.0.2 included). We're planning to move to Spring 4.1.6, however for now we are not able to proceed due to internal reasons (changes need to be made and released in a huge codebase which still relies on the old spring-beans.dtd, see SPR-12836 ). For the moment we are wondering if we can move with our development environment to 1.8 target and stay with Spring version 3.2.13. I was trying to investigate what could be the threads of such approach and what will not work after such change. I have done a couple of tests (introduced a couple of Java 8 features to the code) but for now it seems to me that everything works just fine (at least from the functionalities we use at the moment). Can you please explain what problems/limitations we may face if we move to 1.8 target without upgrading Spring version to 4? I would be grateful for your opinion on this topic. Cheers, Przemek
          Hide
          juergen.hoeller Juergen Hoeller added a comment -

          Hi Przemek,

          With straightforward use of -target 1.8, there aren't many limitations to begin with. Spring 3.2.13 even includes the latest ASM 5.0.3 in the meantime, so it's fully up to date at that front. The only part worth noting is the AspectJ version: If you happen to be using AspectJ and in particular load-time weaving, there may be issues on Java 8 unless you upgrade to AspectJ 1.8.5; however, Spring 3.2.13 just supports AspectJ 1.7.4 - we haven't tested it with AspectJ 1.8.x at all.

          Beyond that, Spring 3.2.x simply doesn't include any dedicated Java 8 support: i.e. no JSR-310 date-time, no parameter discovery via -parameters, etc. If you don't intend to rely on those features initially, that's by no means a showstopper. I would just strongly recommend an upgrade to Spring 4.x as soon as you intend to embrace Java 8 more fully. For the time being, using Spring 3.2.13 on Java 8 will get you quite far and is entirely safe for your purposes.

          Note that we'll release 3.2.14 in May, as a minimal maintenance release, so that line is still actively supported for the time being. There's also a 3.2.15 release planned towards the end of this year, again designed as a very minimal maintenance release. Please be prepared that the 3.2.x line will fade out at that point, with its eventual end of life to be expected for mid/late 2016 and in all likelihood just one further maintenance release (3.2.16) to appear until then.

          Hope that helps,

          Juergen

          Show
          juergen.hoeller Juergen Hoeller added a comment - Hi Przemek, With straightforward use of -target 1.8 , there aren't many limitations to begin with. Spring 3.2.13 even includes the latest ASM 5.0.3 in the meantime, so it's fully up to date at that front. The only part worth noting is the AspectJ version: If you happen to be using AspectJ and in particular load-time weaving, there may be issues on Java 8 unless you upgrade to AspectJ 1.8.5; however, Spring 3.2.13 just supports AspectJ 1.7.4 - we haven't tested it with AspectJ 1.8.x at all. Beyond that, Spring 3.2.x simply doesn't include any dedicated Java 8 support: i.e. no JSR-310 date-time, no parameter discovery via -parameters , etc. If you don't intend to rely on those features initially, that's by no means a showstopper. I would just strongly recommend an upgrade to Spring 4.x as soon as you intend to embrace Java 8 more fully. For the time being, using Spring 3.2.13 on Java 8 will get you quite far and is entirely safe for your purposes. Note that we'll release 3.2.14 in May, as a minimal maintenance release, so that line is still actively supported for the time being. There's also a 3.2.15 release planned towards the end of this year, again designed as a very minimal maintenance release. Please be prepared that the 3.2.x line will fade out at that point, with its eventual end of life to be expected for mid/late 2016 and in all likelihood just one further maintenance release (3.2.16) to appear until then. Hope that helps, Juergen
          Hide
          przemyslaw.wyszkowski@cern.ch Przemek Wyszkowski added a comment -

          Hi Juergen

          Thank you very much for your response - it clarifies the issue fully!

          Cheers,
          Przemek

          Show
          przemyslaw.wyszkowski@cern.ch Przemek Wyszkowski added a comment - Hi Juergen Thank you very much for your response - it clarifies the issue fully! Cheers, Przemek

            People

            • Assignee:
              juergen.hoeller Juergen Hoeller
              Reporter:
              zapodot Sondre Eikanger Kvalø
              Last updater:
              Przemek Wyszkowski
            • Votes:
              4 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                2 years, 9 weeks ago