False negative for (very probably) wrong equality check on 'non-primitive' Boolean

[jveraa]

Hi there,

A colleague of mine recently submitted a PR for review where they had the following:

Boolean.TRUE == someObject.isSomething(); // the someObject.isSomething() returns a Boolean object

SonarQube Server v2026.1 running locally at our org did NOT flag this as an issue, while it is as Boolean-s are plain objects:

jshell> Boolean a = Boolean.TRUE
a ==> true

jshell> Boolean b = Boolean.TRUE
b ==> true

jshell> a == b // compare 'pointers'
$3 ==> true // same static object, so true

jshell> Boolean c = new Boolean(1 == 1) // this is what can happen in JSON deserialization
c ==> true

jshell> a == c
$5 ==> false // different object! 

jshell> a.equals(c) // what we should do in 99% of cases
$6 ==> true

Heavily cencored screenshot showing that this really is a Boolean to Boolean comparison. Weirdly IntelliJ thinks this is fine too while it is such an obvious issue, I can’t imagine why you ever want to compare the static Boolean.TRUE (or false) to anything not using equals in 99.9% of cases.

[andres (Andrés García Solares)]

Hey @jveraa, thanks for reporting this! I guess that this would be a false negative for rule S4973. I had a super brief look at the code and it seems we explicitly exclude this scenario. Now, I’m not a dev, so I’m gonna flag this for the team and see if they can tell us more about this, or perhaps point out if there is another rule that should be detecting this.