Line 290 saying As a bug (nullpointer can be thrown)
it goes inside loop only if isValid is true.
on line 281 if submissionMonth is null i am making isValid false
then there is no chance of going to 290
My understanding is that isValid.booleanValue() will return whatever the value of isValid is (true or false)
So
(Line 281 and 282) if submissionMonth is null, isValid will be set to false
(Line 286) A check is performed on whatever the value of isValid is (right now, false). If you want the branch to only be taken if isValid is true, you’d probably want to check something like isValid.booleanValue() == true
(Line 290) submissionMonth is dereferenced, and is still null.
i am asking the possibility for getting a nullpointer on line 290 that too saying it as a bug (prompting developer to change the code)
my belief is if(isValid.booleanValue()) or if(isValid.booleanValue() == true) will result in same
In a block where code don’t run/reach when submissionMonth is null, how can sonar saying it as a bug
As a java developer since 12 years i don’t want to ask by subordinates to fix a bug(as per sonar)
which is not a bug in my view. That’s why messaged your team.
i prefer a scenario to get nullpointer or a fix in further versions.
I had a closer look at your issue: this seems indeed like a false positive.
The analyzer is able to follow correctly that isValid will always be false when submissionMonth is null. However, it somehow gets confused by the usage of booleanValue(). Using it or not is strictly equivalent, this is in fact exactly what the compiler will do to unbox the value if you don’t call the method (see jls-5.1.8). If you remove it, or use a primitive boolean instead, the issue will dissapear.
Ticket created to improve the situation: SONARJAVA-4242.
Using .booleanValue() to resolve S5411 sounds strange to me, it will not prevent the NPE if isValid is null at one point. One could argue that it makes explicit that you considered the case and it should never be null, but I would rather use the compliant solution from the rule Boolean.TRUE.equals(b) or use the primitive boolean, to make the code safe in case of inattentive refactoring.