Beyond just formally declaring the current behavior, this revision actually enforces non-null behavior in selected signatures now, not tolerating null values anymore when not explicitly documented. It also changes some utility methods with historic null-in/null-out tolerance towards enforced non-null return values, making them a proper citizen in non-null assignments.
Some issues are left as to-do: in particular a thorough revision of spring-test, and a few tests with unclear failures (ignored as "TODO: NULLABLE") to be sorted out in a follow-up commit.
Issue: SPR-15540
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
We should no longer rely on MYISAM for the sequence table since this
engine might not always be available. After this change the storage
engine used by the sequence table can be MYISAM or INNODB since the
sequences are allocated using a new connection without being
affected by any other transactions that might be in progress.
To allow users to fall back on the original functionality of using
MYISAM tables for the incrementer, we add a `useNewConnection` flag to
indicate whether or not to use a new connection for the incrementer.
This flag defaults to true.
Issue: SPR-15107
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
ScriptUtils contains two calls to String#toCharArray for the sole
purpose to iterating over all chars in a String. Not only is this
unnecessary and can be replaced with String#charAt it also causes
additional allocator and heap pressure because String#toCharArray
rather than returning the backing array (which is gone in Java 9)
creates a copy.
This commit contains the following changes:
- remove String#toCharArray from ScriptUtils and replace with
String#charAt
Issue: SPR-15075
This commit also migrates from a WeakHashMap to a ConcurrentReferenceHashMap, allowing for concurrent access to existing cache entries.
Issue: SPR-15006
The documentation mentions various NativeJdbcExtractors that no longer
exist. To be specific CommonsDbcpNativeJdbcExtractor and
XAPoolNativeJdbcExtractor no longer exist.
This commit includes the following changes:
* remove CommonsDbcpNativeJdbcExtractor references from Asciidoctor
* remove CommonsDbcpNativeJdbcExtractor references from Javadoc
* remove XAPoolNativeJdbcExtractor references from Asciidoctor
Issue: SPR-14810
Closes gh-1205
String with version 5 the name of Java Platform, Enterprise Edition
changed from J2EE to Java EE. However a lot of the documentation still
uses the term J2EE.
This commit includes the following changes:
* replace J2EE with Java EE where appropriate
This is not a blind search and replace. The following occurrences
remain unchanged:
* references to old J2EE releases, most notably 1.3 and 1.4.
* references to "Expert One-On-One J2EE Design and Development"
* references to "Core J2EE patterns"
* XML namespaces
* package names
Issue: SPR-14811
See gh-1206
Now that OracleLobHandler has finally been removed it should also be
removed from the documentation.
This commit includes the following changes:
* remove OracleLobHandler references from Javadoc
* remove OracleLobHandler references from Asciidoctor
Issue: SPR-14809
Closes gh-1204
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