SonarJava 5.6 squid:S2589 false positive for nullable value from spring-web if project does depend on findbugs:jsr305

[ahubold (Andreas Hubold)]

Hi,

I already reported this problem for SonarJava 5.3 in https://groups.google.com/forum/#!msg/sonarqube/5ecjTWHt1YY/KZoVswvFCwAJ and you opened https://jira.sonarsource.com/browse/SONARJAVA-2785.

SONARJAVA-2785 is now marked as fixed for version 5.5 but I can still reproduce the original problem with SonarJava 5.6 with the exact same reproducer as in the original post.

Can you please check?

Thank you,
Andreas

[tyrel (Tyrel Haveman)]

I seem to also be still seeing this problem in SonarJava 5.6 on SonarQube 6.7.5 LTS.

The code I have is calling Spring’s Environment.getProperty which is inherited from AbstractEnvironment.getProperty which implements PropertyResolver.getProperty; both are annotated with @Nullable from org.springframework.lang.

The code looks something like this:

public boolean isServiceUp() {
  String healthUrl = getHealthUrl();
  RestTemplate restTemplate = null != healthUrl ? getRestTemplate() : null;
  // ....
}

private String getHealthUrl() {
  return env.getProperty(serviceName);
}

The SonarQube UI is highlighting null != healthUrl as always evaluating to true.

The steps it’s giving are:

1. ‘getProperty()’ can return not null
2. ‘getHealthUrl()’ returns not null.
3. Implies ‘healthUrl’ is not null.
4. Expression is always true.

The weird this is that it’s changing “can return not null” into “returns not null”. Yes, it can return not null, but it can also return null, and in that case this expression evaluates to false. Why is it missing that?

[alban.auzeill]

Hi Andreas and Tyrel,

Yes the problem still exits, I can reproduce it in a small spring project. The support of spring annotations implemented in SONARJAVA-2785 was not tested without jsr305 binary and has a bug in this case.

I have created the bug fix ticket SONARJAVA-2864 to fix this problem in the next version.

Thanks for your feedback,
Alban Auzeill