- Avoid the use of assertThat(Arrays.equals(...))
- Convert assertThat(Boolean.FALSE).isEqualTo(x) to assertThat(x).isEqualTo(Boolean.FALSE)
- Convert assertThat(Boolean.TRUE).isEqualTo(x) to assertThat(x).isEqualTo(Boolean.TRUE)
- Convert assertThat(x.equals(y)).isTrue() to assertThat(x).isEqualTo(y)
- Convert assertThat(x.equals(y)).isFalse() to assertThat(x).isNotEqualTo(y)
- Remove unnecessary parentheses in assertThat() arguments
- Convert assertThat(x instanceof X).isFalse() to assertThat(x).isNotInstanceOf()
- Convert assertThat(x instanceof X).isTrue() to assertThat(x).isInstanceOf()
- Convert assertThat(!x).isTrue() to assertThat(x).isFalse()
- Inline conditions in assertThat() statements
Closes gh-36504
(cherry picked from commit e1e4d52b61)
Although this commit also changes the visibility of some test methods
to package-private, the remainder of that task will be addressed in
conjunction with gh-36496.
Closes gh-36495
(cherry picked from commit 4c14abf0cd)
Since the Spring Framework uses American English spelling, this commit
updates Javadoc and the reference manual to ensure consistency in that
regard. However, there are two exceptions to this rule that arise due
to their use within a technical context.
- We use "cancelled/cancelling" instead of "canceled/canceling" in
numerous places (including error messages).
- We use "implementor" instead of "implementer".
Closes gh-36470
(cherry picked from commit 17699103dc)
Prior to this commit, the determineBasicProperties() method in
PropertyDescriptorUtils did not reliably resolve read/write methods in
type hierarchies with generics. This utility method is used by
SimpleBeanInfoFactory which is used by BeanUtils and BeanWrapperImpl.
Thus, failure to reliably resolve read/write JavaBeans methods resulted
in bugs in certain scenarios.
For example, BeanUtils.copyProperties() randomly failed to copy certain
properties if the write method for the property could not be resolved.
To address such issues, this commit revises the implementation of
PropertyDescriptorUtils as follows.
1) Read methods with covariant return types are now consistently
resolved correctly.
2) If multiple ambiguous write methods are discovered, the algorithm now
checks for an exact match against the resolved generic parameter type
as a fallback.
Closes gh-36019
(cherry picked from commit 4b07edbaeb)
This is not actually triggered on 6.2.x but nevertheless worth aligning.
Includes fix for return type declaration in PropertyAccessor subclasses.
Includes related polishing from main commits.
See gh-36024
Prior to this commit, Spring Framework's JSP form tags supported the
response encoding in most places; however, <form:select> and
<form:options> still did not support the response character encoding.
To address that, this commit updates SelectTag, OptionsTag, and
OptionWriter to provide support for response character encoding in the
`select` and `options` JSP form tags.
See gh-33023
Closes gh-35783
Prior to this commit, a NoUniqueBeanDefinitionException was thrown when
multiple primary beans were detected within a given set of beans, but
nothing was logged. For use cases where the exception is handled by
infrastructure code, it may not be obvious to the developer what the
problem is.
To address that, a TRACE message is now logged whenever multiple
competing primary beans are detected in DefaultListableBeanFactory.
Closes gh-35550
This commit fixes code generation for a bean produced by a protected
factory method. Previously only the code generated for public methods,
i.e. without a dedicated instance supplier method, was handled.
Closes gh-35486
The compiler has a constants pool limit of 65536 entries per source file
which can be hit with a very large amount of beans to register in the
bean factory.
This commit makes sure to create separate source files if the number
of beans to register is very large. The main generated source file
delegate to those.
Closes gh-35044
Prior to this commit, argument index handling in
AutowiredArgumentsCodeGenerator suffered from an off-by-one error when
generating code for an autowired inner class constructor.
Since the startIndex is already properly calculated for an inner class in
InstanceSupplierCodeGenerator.buildGetInstanceMethodForConstructor(...),
there is no need to adjust the argument indexes within
AutowiredArgumentsCodeGenerator.generateCode(...).
Closes gh-34974
Signed-off-by: Dmytro Nosan <dimanosan@gmail.com>
Juergen Hoeller