final Long lastProcessedTimestamp =  jdbcTemplate.queryForObject(query, Long.class, tenant, subProcess);
return  lastProcessedTimestamp == null ? Long.MIN_VALUE : lastProcessedTimestamp.longValue();
 ‘queryForObject()’ can return not null.
 Implies ‘lastProcessedTimestamp’ can be not null.
 Expression is always false.
lastProcessedTimestamp can be null and not null. Then  cannot be always false.
SonarQube version: 18.104.22.168531
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
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)
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 22.214.171.12447
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 126.96.36.199043
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
Subsequent 9.0.0 summary
Details of the 1 open bug in 9.0.0