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.
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 4.7.0.2747
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 9.7.1.62043
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
