| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Instantiate beans with a private injected constructor reflectively (#13136) * Instantiate beans with a private injected constructor reflectively ClassElement#getPrimaryConstructor never selects a private constructor, so a bean whose @Inject constructor is private got no constructor and the bean definition fell back to a synthesized public no-arg <init>, invoked directly. At runtime that failed with IllegalAccessError, or silently used a public constructor instead of the @Inject one. The user guide says a private @Inject constructor is instantiated with reflection. BeanInjectionUtils#findBeanConstructor extends the primary constructor lookup: a private constructor annotated with @Inject or @Creator takes precedence over an unannotated accessible one, and a type whose only constructor is private uses it. The constructor definition now requires reflection via isReflectionRequired(); !isAccessible() inverted the flag for a private constructor carrying @ReflectiveAccess. Around advice cannot be applied to such a bean, since the generated proxy subclass has to call the constructor, so that now fails compilation naming the type. The GraalVM visitor registers the private constructor it previously could never see. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix: require ReflectiveAccess for private bean constructors * Fail compilation when an injected private constructor is not reflective A private constructor is only selected when it is annotated with @ReflectiveAccess, so @Inject or @Creator on a private constructor without it silently did nothing: the bean either used another constructor or was not created at all. BeanInjectionUtils#validateBeanConstructor now rejects that combination from BeanDefinitionCreatorFactory, the single entry point for bean creation, so the error is reported even for a class that would not otherwise be a bean. The message names @ReflectiveAccess as the fix. An unannotated private constructor is left alone, so the implicit constructor of a private type and a factory with only static methods still compile. The constructor injection guide said such a type was instantiated reflectively; it now describes the opt-in and the AOP restriction. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> | 3 天前 | |
Fix Kotlin default dispatch for inherited methods (#12670) * Fix Kotlin default dispatch for inherited methods * Prevent recursive override traversal in DispatchWriter | 4 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 天前 | ||
| 4 个月前 |