In my java project, I have a java bean which have the @NotNull annotation. But actually we don’t use validator to check the bean input. So the field is possible null. And then in some place we check the field != null then sonar submit a bug Change this condition so that it does not always evaluate to "true".
I think sonar should not restrict based on mutable facts, e.g. annotation which may be implemented or not implemented, or result may be different. At least should not submit a major bug.
I’m pretty sure SonarSource employees will ask you which @NotNull annotation exactly you use. Please post the fully qualified class name of the annotation (i.e. the import ....NotNull line).
Also, when reporting suspected bugs or suggestions, always include the key of the respective SonarJava rule - for example, the rule this thread is about is called S5128. In SonarQube/SonarCloud, the rule key is displayed in the upper right corner of the rule description window.
I just made a simple sample to reproduce this. Pls take a look. I found the rule id is s2583.
package test;
import javax.validation.Valid;
import javax.validation.constraints.NotNull;
public class MyBean {
public String name = null;
public static void main(String[] args) {
MyBean myBean = new MyBean();
if (myBean.getName() != null){
System.out.println("I am not null");
}else {
System.out.println("I am null");
}
}
@NotNull
@Valid
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
Actually we can use this Bean inside our code to get/set without validation or use validation if it is needed, that’s depends on use cases.
Thank you for your suggestion.
It is similar to this thread and this other one. I will look into it. this change would create false negatives as there are valid contexts in which @NotNull actually means that the annotated item will not be null.
I moved your posts to a separate thread because it had no relation with the original thread. Please use the “Report a Bug”->“False-positive” category to report rules raising unexpected issues.
@bannmann Thank you for explaining the information we need. It helped a lot.
Sorry for the absence of update.
We will fix this issue but it requires a big engineering effort. The problem is described here: MMF-1767. You can follow this ticket to see when it will be fixed.
I can’t give any deadline yet but this is in our todo-list. In the meantime the simplest solution remains to disable the rule.