False Negative: EqualsArray.ql misses array identity comparisons once the array is widened to `Object` or routed through helper APIs.

[Carlson-JLQ]

False Negative: EqualsArray.ql misses array identity comparisons once the array is widened to Object or routed through helper APIs.

Version
codeql 2.24.3

Checker

• Checker id: Likely Bugs/Comparison/EqualsArray.ql
• Checker description: Detects calls to equals or hashCode methods on array objects, which compare object identity rather than array contents.

Description of the false negative

These samples still use array identity operations where content comparison was almost certainly intended. The difference is only that the array is first widened to Object or compared through Objects.equals(...), which still ends up using reference equality for arrays.

Affected test cases

PosCase1_Var2.java

Widening the array to Object does not change the fact that equals still performs identity comparison.

// Calling hashCode() on an array should be flagged as comparing object identity.
package scensct.var.pos;

public class PosCase1_Var2 {
    public static void main(String[] args) {
        // Variant 2: Intra-procedural refactoring - using a temporary reference
        int[] arr = {1, 2, 3};
        Object objRef = arr;
        int hash = objRef.hashCode(); // Still calling hashCode on the array object
        System.out.println(hash);
    }
}

PosCase2_Var1.java

Calling equals(Object) on the array still compares object identity rather than contents.

// Calling equals(Object) on an array with compatible array argument should be flagged as comparing object identity.
package scensct.var.pos;

public class PosCase2_Var1 {
    public static void main(String[] args) {
        Integer[] a = {1, 2, 3};
        Integer[] b = {1, 2, 3};
        // Using a temporary variable to alias the array
        Object obj1 = a;
        Object obj2 = b;
        boolean same = obj1.equals(obj2);
        System.out.println(same);
    }
}

PosCase2_Var2.java

The helper API does not change the semantics of array equals; it is still an identity comparison.

// Calling equals(Object) on an array with compatible array argument should be flagged as comparing object identity.
package scensct.var.pos;

import java.util.Objects;

public class PosCase2_Var2 {
    public static void main(String[] args) {
        String[] arr1 = {"x", "y"};
        String[] arr2 = {"x", "y"};
        // Using Objects.equals which internally calls equals on the first argument
        boolean result = Objects.equals(arr1, arr2);
        System.out.println(result);
    }
}

Cause analysis

The query appears to recognize only direct array.equals(...) or array.hashCode() calls on obviously array-typed expressions. Once the array is widened to Object or the call is wrapped by a library helper like Objects.equals(...), the identity-based behavior is no longer modeled.

That is a real usability gap. Developers often pass arrays through generic APIs before comparing them, and the bug remains the same.

References

None known.

[redsun82]

@Carlson-JLQ thanks. The Objects.equals(arr1, arr2) variant is an interesting one — that's an API developers actually reach for. The widened-to-Object cases are less likely to occur in practice. As I mentioned on #21546, findings backed by real-world examples carry much more weight for us.