Fix/optimize handling of @Bean method override regression with return type narrowing on JDK 8 [SPR-11718]

[spring-projects-issues]

Oliver Drotbohm opened SPR-11718 and commented

Overriding an @Bean method with a narrowed return type is working fine with Spring 3.2.8 on legacy JDKs (6 and 7). However, it's breaking with Spring 3.2.8 on JDK 8. Spring 4.0 on JDK 8 fixes this already, as part of general @Bean overload support. For Spring 3.2.9, we should do a minimal fix for the regression on JDK 8, even if we're not allowing overloaded @Bean methods in the same class yet.

---

Affects: 3.2.8

Issue Links:

• ConfigurationClass.validate() should allow for overloading in general or not at all [SPR-11025] #15653 ConfigurationClass.validate() should allow for overloading in general or not at all
• 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)

Backported to: 3.2.9

[spring-projects-issues]

Juergen Hoeller commented

It turns out that it's generally worthwhile to ignore bridge methods in our annotation method detection algorithms. As of JDK 8, bridge methods carry the same annotations as the corresponding original methods. However, we always want to operate on original methods anyway, exposing each annotated method just once that way (even on JDK 8).

In Spring Framework 4.x, we allow overloaded @Bean methods in general, simply picking the closest match at runtime. This works fine with the same method registered multiple times, as in our JDK 8 case here. Nevertheless, we should actively exclude bridge methods there as well since it doesn't serve any purpose to consider them, and may lead to subtle runtime differences between JDKs.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

I'll apply this bridge method exclusion fix to master and 4.0.x as well since it's a generally worthwhile optimization.

We're also explicitly skipping introspection on java.* classes since we'll never find @Bean annotations there anyway. Previously, we optimized their introspection through always using reflection instead of ASM. However, it's actually pointless to even go that far since we'll never find Spring annotations there in the first place.

Juergen