Basic Java 8 bytecode compatibility for Spring 3.2.x through ASM 5.0.2 [SPR-11656]

[spring-projects-issues]

Sondre Eikanger Kvalø opened SPR-11656 and commented

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.

---

Affects: 3.2.8

Issue Links:

• Upgrade AspectJ dependency to 1.8 final and apply latest ASM 5.0.2 patches [SPR-11212] #15837 Upgrade AspectJ dependency to 1.8 final and apply latest ASM 5.0.2 patches
• Upgrade embedded ASM version to 5.0.1 [SPR-11239] #15864 Upgrade embedded ASM version to 5.0.1
• Java 8: ASM5 visitors required for parsing INVOKESPECIAL/STATIC on interfaces [SPR-11979] #16595 Java 8: ASM5 visitors required for parsing INVOKESPECIAL/STATIC on interfaces
• Upgrade to ASM 5.0.3 [SPR-11889] #16508 Upgrade to ASM 5.0.3
• Metadata reading should never use ASM for java.* and javax.* types (in particular on JDK 8) [SPR-11719] #16341 Metadata reading should never use ASM for java.* and javax.* types (in particular on JDK 8)

Referenced from: pull request #510

4 votes, 9 watchers

[spring-projects-issues]

Morten Kjetland commented

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

[spring-projects-issues]

Juergen Hoeller commented

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

[spring-projects-issues]

Juergen Hoeller commented

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

[spring-projects-issues]

Juergen Hoeller commented

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

[spring-projects-issues]

Juergen Hoeller commented

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

[spring-projects-issues]

Przemek Wyszkowski commented

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 #17433). 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

[spring-projects-issues]

Juergen Hoeller commented

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

[spring-projects-issues]

Przemek Wyszkowski commented

Hi Juergen

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

Cheers,
Przemek