According to the JDK's documentation and changelog, the Introspector itself safely handles weak references as of JDK 6 update 21 (which is what we require for Spring 4.0).
Issue: SPR-11356
This in particular allows for specifying "spring.getenv.ignore" and "spring.beaninfo.ignore" in a local way within the application, in case that JVM-level system properties are locked.
Issue: SPR-9014
Issue: SPR-11297
This allows us to avoid early initialization of footprint-heavy ConcurrentHashMaps, and reuses the existing postProcessingLock which will typically be active already when registerExternallyManaged* calls come in from the bean factory's post-processing phase.
Issue: SPR-11343
Specifically, read and write methods are allowed to express property types with superclass/subclass relationships in both directions now.
Issue: SPR-11139
Specifically, if the current factory has Qualifier/ContextAnnotationAutowireCandidateResolver set up, it is important to pass it on to ancestor factories to get consistent qualifier matching results.
Issue: SPR-10966
Our per-bean caching in AutowiredAnnotationBeanPostProcessor and co relies on unique bean names, so this change fixes potential cache mismatch problems occuring there.
Issue: SPR-11131
Attempt to improve performance by caching TypeDescriptors against bean
PropertyDescriptors in CachedIntrospectionResults.
This change is an attempt to fix the failing performance test case
`testPrototypeCreationWithOverriddenResourcePropertiesIsFastEnough` in
`AnnotationProcessorPerformanceTests`.
Apply consistent styling to new classes introduced in Spring 4.0.
- Javadoc line wrapping, whitespace and formatting
- General code whitespace
- Consistent Assert.notNull messages
Fix a variety of typos throughout the project, primarily in
comments (javadoc or otherwise) but also in a handful of log messages
and a couple exception messages.
ISSUE: SPR-11123
Fix remaining Java compiler warnings, mainly around missing
generics or deprecated code.
Also add the `-Werror` compiler option to ensure that any future
warnings will fail the build.
Issue: SPR-11064
Since @Bean methods are never used with externally specified constructor argument values but rather just with autowiring, the non-lenient constructor resolution mode is appropriate in case of an overloaded @Bean method, not performing any type difference weight checks. This change includes a refinement of Spring's existing non-lenient constructor resolution (which needs to be explicitly turned on and is therefore not well tested), narrowing the conditions for the ambiguity check (only in case of the same number of arguments and not for overridden methods).
Issue: SPR-10988
XML-defined arguments values are initially turned into TypedStringValue wrappers. If we encounter an unresolved argument, we need to unwrap such a TypedStringValue and then try to treat its content as a class name.
Issue: SPR-11034