SonarQube Server: v2025.1 (102418)
SonarQube for IDE: 10.15.0.80347
public record ExampleObject(@org.springframework.lang.Nullable String value) {
}
When I pass null to this object SonarQube server complains that the field is not annotated as Nullable (java:S4449). However, this issue is not shown by SonarQube for IDE unless I remove the Nullable annotation.
Annotating it with javax.annotation.Nullable instead does not help.
It may be relevant to point out that package-info.java is annotated with org.springframework.lang.NonNullApi, so it may be that Sonar is getting confused about which annotation has priority. Though my entire project is annotated NonNullApi at the package level, so this would be surprising.
Even stranger is that not all usages where null is passed are reported.
In one place I have done this to reproduce. Issue reported on line 1 and 2.
1. new ExampleObject(null);
2. return new ExampleObject(
3. obj.getValue().orElse(null)
4. );
But then in a different file I added this and it was not reported.
I’m asking because a common causes of FPs like this (that appear in SonarQube Server but not SonarQube for IDE) is that while SonarQube for IDE has a lot of context about the project (including dependencies, libraries), as does the Scanner for Maven/Gradle, that information is often missing when using the Scanner CLI.
Thank you for reporting the issue and providing a clear explanation. I investigated but couldn’t reproduce the problem with your example. The symbolic execution engine used by the rule is quite complex, and reproducing a bug without the full context can be tricky, which might explain the inconsistent behavior you’re experiencing.
For now, I recommend marking these issues as false positives.
Differently to Lars, I’m using the @jakarta.annotation.Nullable annotation, but I believe the source to be the same.
I’ve tested it with a local SonarQube running with default settings in docker, as documented in the repository. I’m using the gradle plugin to execute a test run against the repository. However, I also get the same issue in a CI run on linux.
I hope that helps to triage why the issue is being created.
Thank you for sharing the reproducer with us—it’s really helpful. I was able to use the example to reproduce the issue. I’m looking into the issue now, and I’ll create a ticket once I have more information. I’ll keep you updated on our progress.