java:S2583 FP - Change this condition so that it does not always evaluate to "false"

[2] final Long lastProcessedTimestamp = [1] jdbcTemplate.queryForObject(query, Long.class, tenant, subProcess);
return [3] lastProcessedTimestamp == null ? Long.MIN_VALUE : lastProcessedTimestamp.longValue();

Analysis result:

[1] ‘queryForObject()’ can return not null.
[2] Implies ‘lastProcessedTimestamp’ can be not null.
[3] Expression is always false.

So lastProcessedTimestamp can be null and not null. Then [3] cannot be always false.

SonarQube version:

Hello @elmuerte ,

Thank you for the feedback and reproducer. This on has been quite hard to unroll, has it has deep root in our code. The FP is caused our engine not recognizing JdbcTemplate#queryForObject(...) has being nullable. Note that if you would have used the Interface JdbcOperations instead of its implementation JdbcTemplate (and assuming you are using spring-jdbc >= 5.0.0), then the issue should disappear.

I created the following ticket to tackle it: SONARJAVA-4342


1 Like

I have another FP that appears similar to me, but I don’t think the root cause matches your explanation. To me, this looks like a logic error between determining that something can be not null vs cannot be null.

My example is also from Spring though, and there happens to be an @Nullable annotation.

Method in question is JobExecution (Spring Batch 4.3.7 API)

Code is

Analysis says

Javadoc for the method in question

There are other instances of this flagged in code for the other dates in JobExecution, such as end time (also @Nullable) and create time (not annotated nullable and in practice won’t be null but I am not sure that there is a guarantee of that in the code so i think that sonarjava should not be assuming it won’t be null and flagging tests for nullness as always false)

If it matters, the analysis was triggered via jenkins 2.361.2 sonarqube scanner for Jenkins 2.14

INFO: SonarScanner
INFO: Java 11.0.12 Red Hat, Inc. (64-bit)
INFO: Linux 4.18.0-305.3.1.el8_4.x86_64 amd64
INFO: Analyzing on SonarQube server

Spring Batch jar is 4.3.7

Following up on my previous comment, this rule and it’s partner java:S2289 do not work together coherently/consistently.

Changing the code to remove the check for null passed the quality profile for the PR and then failed later once in the main build (branch 9.0.0-branch).

The same method as above is now flagged as a bug by java:S2289 after removing the null check

PR code changes

PR summary

Subsequent 9.0.0 summary

Details of the 1 open bug in 9.0.0