* Test for multi-line comment block where the comment end delimiter occurs on a line starting with the single-line comment prefix
* ScriptUtils successfully parses a SQL script containing a multi-line comment block where the comment-end delimiter occurs on a line starting with the single-line comment prefix.
Prior to this commit, ScriptUtils supported MySQL-style escapes ('\\')
when splitting a script into statements; however, MySQL-style escapes
were not supported when determining if a given script contained a
specified statement delimiter. This caused executeSqlScript() to
erroneously fallback to a newline as the statement separator in such
cases.
This commit fixes this issue by implementing the same check for
MySQL-style escapes in containsSqlScriptDelimiters() that was already
present in splitSqlScript().
Issue: SPR-17120
Polish a few issue identified when adding checkstyle to the
build. Although checkstyle is not enforcing rules on tests,
these are a few minor changes that are still worth making.
Issue: SPR-16968
In my opinion, we should parse ":{x}" style parameter as "x" is parameter using "NamedParameterUtils.parseSqlStatement",
so the condition "j - i > 2" is the correct condition, not "j - i > 3", because if "i" is the index of
":" in ":{x}", and "j" is the index of "}" in ":{x}", "j - i == 3" is true.
Also add a test case for SPR-16663.
Includes related polishing in core.metadata and datasource.embedded and a revision of the corresponding database definitions in sql-error-codes.
Issue: SPR-16558
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
Sam Brannen
Mansur Mustaquim
Sebastien Deleuze
Rossen Stoyanchev
Juergen Hoeller
Stephane Nicoll
Hanope
Chris Harding
Phillip Webb
Johnny Lim
nkjackzhang
Kazuki Shimizu
igor-suhorukov
arturgspb
Mario Arias
Philippe Marschall