is followed by an IF condition to check if gridFsFile is either null or not null
if (gridFsFile == null) {
...
} else {
...
}
then Sonar raises a java:S2583.
An example is in the attached image.
Why java:S2583 is reported is incomprehensible to me: GridFsTemplate.findOne(…) does not have any @NonNull annotation. Moreover the analysis explanation is really confusing:
Change this condition so that it does not always evaluate to "false"
Bug
'findOne()' can return not null.
Implies 'gridFsFile' can be not null.
Expression is always false.
If gridFsFile can be not null (“can be” means that it can also be the opposite, i.e. null) why the expression is marked as always false? It’s really confusing…
Hi Ann,
thanks for the finding.
I absolutely agree, with a caveat: following the example reported in SONARJAVA-4285 the Javadoc of JpaRepository.getById indicates (as a simple text) that this is very likely to always return an instance and throw an EntityNotFoundException on first access, thus suggesting something like a @NonNull annotation. In my example the Javadoc of GridFsTemplate.findOne doesn’t imply a non-null result (neither from an annotation nor from a textual comment). So I think my example enforce SONARJAVA-4285 with a more strong argument against the false positive.
Thanks for the message. I had a look into the reported issue. Unfortunately, I can’t reproduce it. It means I need some more information about your example. Is it coming from MongoDB and which version of it are you using? Did you have any warnings in your logs?
Also, any chance you’re using a package annotation com.mongodb.lang.NonNullApi or org.springframework.lang.NonNullApi? This annotation says that return values are considered not to be null, which could actually trigger the issue as the Java analyzer is able to understand such annotations.
I installed in Eclipse the latest version of Sonarlint (7.6.0.58887) directly using the Eclipse update site downloaded from the distribution server.
I executed Sonarlint on my project (it’s a Gradle multi-project) and the java:S2583 did not appear.
Based on SONARJAVA-4285 I uninstalled Sonarlint 7.6, replacing it with the version mentioned in the Jira issue (7.4, more specifically I installed the version 7.4.0.46482).
Executing Sonarlink 7.4 on my project the java:S2583 appeared.
So I can say that, from a Sonarlint point of view, the issue is resolved and not reproducible, as you already stated.
Is it possible that instead an analysis triggered by the following configuration is still bugged ?
Analysis triggered by a Jenkins (2.375.1) pipeline using SonarQube Scanner Plugin Version: 2.15
SonarQube Community Edition Version 8.9.10 (build 61524)
In other words: does SonarQube SonarQube Community Edition Version 8.9.10 (build 61524) is “older” than the Sonarlint 7.6.0.58887 and therefore I need to wait for a newer version of the SonarQube Community Edition in order to see the issue disappear also there?
EDIT: I upgraded the server to Community Edition Version 9.8 (build 63668). The java:S2583 did not appear.
So in summary I think my project hit a SonarQube bug which is resolved in recent versions of SonarQube. As a side note, the SONARJAVA-4285 bug seems still present: nothing changed with Sonarlint 7.6 and the false positive is still generated.
Hey @Aldo_Bongio,
Sorry, I missed you are on the LTS. Yes, SQ 8.9.10 is much older than SQ 9.8. And yes, looks like the issue was fixed after the 8.9.10 LTS. So yes, we recommend you use the latest one to eliminate issues like this. And keep in mind that if you’re using connected mode analyzers are downloaded from the server, so you can still have an outdated result because of the old SQ version even on the latest SL.
About the SONARJAVA-4285, the ticket is still open, so no progress on that side yet.
