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

Make DefaultListableBeanFactory's javax.inject.Provider implementation invisible for nested class introspection [SPR-17014] #21552

Closed
spring-issuemaster opened this Issue Jul 6, 2018 · 1 comment

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

spring-issuemaster commented Jul 6, 2018

Dave Syer opened SPR-17014 and commented

DefaultListableBeanFactory has some nested types that are designed to protect the runtime against class not found errors when certain libraries are not on the classpath (in particular JSR330). Unfortunately, some static analysis tools cannot get past the fact that one of those inner classes implements an interface Provider that is not available at runtime.

Here's a program that fails when javax.inject is not on the classpath:

public class Test {
 public static void main(String[] args) throws Exception {
   Class<?> clazz = Class.forName( "org.springframework.beans.factory.support.DefaultListableBeanFactory$DependencyObjectProvider");
   System.out.println(clazz.getEnclosingClass());
 }
} 

It seems like a "feature" of the JDK, but I think we can easily work around it by extracting the private nested class into a package private one.


Affects: 5.0.7

Reference URL: oracle/graal#511

Issue Links:

  • #21529 Initial GraalVM native images (Substrate VM) support ("is depended on by")

Referenced from: commits b4fc794

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Jul 6, 2018

Juergen Hoeller commented

There's an easy way out: moving Jsr330DependencyProvider to a nested class of Jsr330ProviderFactory, that is, one level deeper. This allows us to keep them as non-static inner classes but nevertheless make the HotSpot/Graal introspection problem go away, as far as I can tell.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment