False Positive: Benchmark-excluded boxed primitive comparisons are still treated as incorrect reference equality.

[Carlson-JLQ]

False Positive: Benchmark-excluded boxed primitive comparisons are still treated as incorrect reference equality.

Version
2.48.0

Checker

• Checker id: BoxedPrimitiveEquality
• Checker description: Detects equality comparisons (== or !=) where both operands are boxed primitive types, which may incorrectly use reference equality instead of value equality.

Description of the false positive

diff/output marks 2 false positives for BoxedPrimitiveEquality. Across these samples, the checker tends to fire on the outer syntax while missing code-level cues that make the pattern harmless, exempted, or at least much weaker than a real bug. The recurring themes are string reference equality.

Affected test cases

NegCase1.java

Source: output/codeql/RefEqBoxed/src/main/java/scensct/core/neg/NegCase1.java

The core operation is a reference-equality check involving strings. A human reader would likely classify this as an allowed or intentionally structured pattern rather than a bug. That matches the benchmark's stated intent: Reference equality comparison where left operand is not a boxed numeric type should not be flagged as suspicious.

// Reference equality comparison where left operand is not a boxed numeric type should not be flagged as suspicious.
package scensct.core.neg;

public class NegCase1 {
    public static void main(String[] args) {
        // Scenario 1: left operand is primitive int
        int a = 5;
        int b = 5;
        boolean comp1 = (a == b); // primitive comparison, not boxed

        // left operand is String
        String s1 = "hello";
        String s2 = "hello";
        boolean comp2 = (s1 == s2); // String reference comparison, not boxed numeric

        // left operand is Boolean
        Boolean bool1 = Boolean.TRUE;
        Boolean bool2 = Boolean.TRUE;
        boolean comp3 = (bool1 == bool2); // Boolean comparison, excluded by checker

        // left operand is custom object
        Object obj1 = new Object();
        Object obj2 = new Object();
        boolean comp4 = (obj1 == obj2); // custom object comparison, not boxed numeric
    }
}

NegCase3.java

Source: output/codeql/RefEqBoxed/src/main/java/scensct/core/neg/NegCase3.java

The sample keeps the benchmark's target pattern but expresses it in a slightly non-canonical source form. A human reader would likely classify this as an allowed or intentionally structured pattern rather than a bug. That matches the benchmark's stated intent: Reference equality comparison where at least one operand is java.lang.Boolean should not be flagged as suspicious.

// Reference equality comparison where at least one operand is java.lang.Boolean should not be flagged as suspicious.
package scensct.core.neg;

public class NegCase3 {
    public static void main(String[] args) {
        Boolean bool1 = Boolean.TRUE;
        Boolean bool2 = Boolean.FALSE;
        Integer intVal = Integer.valueOf(5);

        // Scenario 3: both operands are Boolean
        boolean comp1 = (bool1 == bool2); // Boolean == Boolean, excluded

        // Boolean == Integer
        boolean comp2 = (bool1 == (Object) intVal); // at least one is Boolean, excluded

        // Integer == Boolean (left is boxed numeric, right is Boolean)
        boolean comp3 = ((Object) intVal == bool1); // at least one is Boolean, excluded
    }
}

Cause analysis

The rule is documented as follows: Detects equality comparisons (== or !=) where both operands are boxed primitive types, which may incorrectly use reference equality instead of value equality.

In this set the problem shows up around string reference equality. The implementation appears to lean too heavily on surface indicators and not enough on what the code actually does.

That is why these reports read like over-approximation. The code often retains a suspicious signature or control-flow skeleton, but once you read the body, the benchmark's claimed exemption is visible in the source itself.

For BoxedPrimitiveEquality, the practical improvement would be to model those source-level exemptions more explicitly instead of reporting every syntactic near-match.

References

None known.