Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue Apr 22, 2014 · 2 comments
Assignees
Labels
in: core status: backported type: enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Apr 22, 2014

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:

  • #15653 ConfigurationClass.validate() should allow for overloading in general or not at all
  • #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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Apr 24, 2014

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Apr 25, 2014

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core status: backported type: enhancement
Projects
None yet
Development

No branches or pull requests

2 participants