This commit introduces 2 new @Nullable and @NonNullApi
annotations that leverage JSR 305 (dormant but available via
Findbugs jsr305 dependency and already used by libraries
like OkHttp) meta-annotations to specify explicitly
null-safety of Spring Framework parameters and return values.
In order to avoid adding too much annotations, the
default is set at package level with @NonNullApi and
@Nullable annotations are added when needed at parameter or
return value level. These annotations are intended to be used
on Spring Framework itself but also by other Spring projects.
@Nullable annotations have been introduced based on Javadoc
and search of patterns like "return null;". It is expected that
nullability of Spring Framework API will be polished with
complementary commits.
In practice, this will make the whole Spring Framework API
null-safe for Kotlin projects (when KT-10942 will be fixed)
since Kotlin will be able to leverage these annotations to
know if a parameter or a return value is nullable or not. But
this is also useful for Java developers as well since IntelliJ
IDEA, for example, also understands these annotations to
generate warnings when unsafe nullable usages are detected.
Issue: SPR-15540
Codacy warns about an Error Prone [1] use of the double constructor of
BigDecimal in tests. The reason given is that it is a source of
precision loss if the number does not have an exact double
representation. The recommendation is to use the String constructor of
BigDecimal instead as it does not require using a lossy argument.
This commit contains the following changes:
- replace usage of the double constructor of BigDecimal with the
String constructor of BigDecimal in JdbcTemplateQueryTests
- update the copyright year
[1] http://errorprone.info/bugpattern/BigDecimalLiteralDouble
Issue: SPR-15077
This commit adds a test runtime dependency on log4j 2 for every project
and migrates all log4j.properties files to log4j2-test.xml files.
Issue: SPR-14431
Previously, if a database needs to be initialized with several scripts
and many (or all) use a custom separator, said separator must be repeated
for each script.
This commit introduces a `separator` property at the parent element level
that can be used to customize the default separator. This is available
for both the `initialize-database` and `embedded-database` elements.
Issue: SPR-13792
This commit migrates all remaining tests from JUnit 3 to JUnit 4, with
the exception of Spring's legacy JUnit 3.8 based testing framework that
is still in use in the spring-orm module.
Issue: SPR-13514
Prior to this commit, EmbeddedDatabaseFactory logged the name of an
embedded database just before it was created; however, the name alone
is not sufficient for connecting to the database via external tools
such as the H2 Web Console.
This commit updates EmbeddedDatabaseFactory to make it easier to
connect to embedded databases via external tools by logging the
complete connection URL for an embedded database as it's being created.
In addition, EmbeddedDatabaseFactory now logs when an embedded database
is being shut down.
Issue: SPR-13370
Some databases such as Oracle permit double quoted column aliases that
contain case-sensitive characters, single quotes, and other special
characters; however, prior to this commit, SqlScripts interpreted a
single quote nested within double quotes as the start of a string
literal resulting in improper parsing.
This commit addresses this issue by ensuring that double quoted strings
such as column aliases are properly parsed even when containing single
quotes.
Issue: SPR-13218
Development teams often encounter errors with embedded databases if
their test suite inadvertently attempts to recreate additional
instances of the same database. This can happen quite easily if an XML
configuration file or @Configuration class is responsible for creating
an embedded database and the corresponding configuration is then reused
across multiple testing scenarios within the same test suite (i.e.,
within the same JVM process) -- for example, integration tests against
embedded databases whose ApplicationContext configuration only differs
with regard to which bean definition profiles are active.
The root cause of such errors is the fact that Spring's
EmbeddedDatabaseFactory (used internally by both the
<jdbc:embedded-database> XML namespace element and the
EmbeddedDatabaseBuilder for Java Config) will set the name of the
embedded database to "testdb" if not otherwise specified. For the case
of <jdbc:embedded-database>, the embedded database is typically
assigned a name equal to the bean's id. Thus, subsequent attempts to
create an embedded database will not result in a new database. Instead,
the same JDBC connection URL will be reused, and attempts to create a
new embedded database will actually point to an existing embedded
database created from the same configuration.
This commit addresses this common issue by introducing support for
generating unique names for embedded databases. This support can be
enabled via:
- EmbeddedDatabaseFactory.setGenerateUniqueDatabaseName()
- EmbeddedDatabaseBuilder.generateUniqueName()
- <jdbc:embedded-database generate-name="true" ... >
Issue: SPR-8849
