Java 8: ASM5 visitors required for parsing INVOKESPECIAL/STATIC on interfaces [SPR-11979]

[spring-projects-issues]

Albert Gorski opened SPR-11979 and commented

Spring context does not start when Spring Bean uses, direct or indirect, new
Comparator features:

java.lang.IllegalArgumentException: INVOKESPECIAL/STATIC on interfaces require ASM 5

I attached maven project which reproduces this problem.

---

Affects: 3.2.9

Attachments:

• spring-asm-interface.zip (9.76 kB)

Issue Links:

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

Referenced from: commits ed88155, 10a0390, 29f6f3d, 7a3dd2a

[spring-projects-issues]

Juergen Hoeller commented

This looks like a rather harsh assertion in ASM 5 itself: When encountering that bytecode instruction, it insists on all applied visitors to be ASM-5-based, which some of ours aren't yet. In particular, CGLIB 3.1 still uses ASM-4-based visitors which otherwise works fine...

The problem may exist in the Spring Framework 4.x line as well; I'll try to reproduce it. There, we'd be able to work around it in our custom ASM fork. I'm afraid we won't be able to do that in the Spring Framework 3.2.x line where we're working with stock ASM versions only.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Looks like our own visitors are to blame: They indicate ASM5 level in the 4.x line but still ASM4 level - which they technically are - in the 3.2.x line... We just started including ASM 5.0 as of 3.2.9 there, not doing any modifications to our visitors in that line. However, it starts working fine simply through redeclaring them as ASM5, so we'll do that for the upcoming 3.2.10 release (next week) which should also make your scenario work.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Note that this has always been working fine in the Spring Framework 4.x line. You could try to upgrade to Spring Framework 4.0.6 for the time being...

In any case, I'll fix this for 3.2.10 later today. I'll let you know once a 3.2.10.BUILD-SNAPSHOT is available for testing.

Juergen

[spring-projects-issues]

Albert Gorski commented

Thank you a lot for the extremely fast response.

Unfortunately we cannot update easy to the version 4 because we still use iBatis. So, we have to upgrade our DAOs to use myBatis, first (soon).

[spring-projects-issues]

Juergen Hoeller commented

No worries, we'll make such Java 8 bytecode usage work in 3.2.10 as well. The 3.2.x line won't get any dedicated Java 8 support in the framework (that's just in 4.x) but it at least needs to be Java 8 runtime compatible for all regular scenarios.

For your planning purposes: We'll maintain the 3.2.x line until the end of this year, with a final maintenance release to appear in December. That said, I'd recommend an upgrade to Spring Framework 4.1 which will go GA in August. The MyBatis migration is hopefully worth it as well.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

FYI, the latest 3.2.10.BUILD-SNAPSHOT contains this fix now. Feel free to give it a try...

3.2.10 is scheduled for release on Tuesday July 15th. Thanks for raising this just in time!

Juergen

[spring-projects-issues]

Albert Gorski commented

Works like a charm - thank you very much for fast feedback.

We will start migration ASAP.