You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
java/unchecked-cast-in-equals: missed when the argument is passed to any library method first #22982
The query reports the cast (WAEqualsCallQl) o in seed/WAEqualsCallQl.java: equals casts its argument without a type test, so another type throws ClassCastException. Adding java.util.Objects.requireNonNull(o); before the cast (variant/) silences the alert, but the cast still throws for any other type.
The query exempts an equals that passes the parameter to any method whose body isn't in the database, I guess to allow for a type test in a library helper. requireNonNull doesn't check the type, and the alert message (the method doesn't inspect the argument's type) is still true.
codeql database create db --language=java --build-mode=none \
--source-root=<one directory> --overwrite
codeql database analyze db \
codeql/java-queries:codeql-suites/java-security-and-quality.qls \
--format=csv --output=out.csv
# one database per directory
Expected result
The "Equals method does not inspect argument type" alert on the cast in variant/WAEqualsCallQl.java (line 7), as on seed/ (line 6).
Output of the commands above:
### CodeQL 2.27.2 query: java/unchecked-cast-in-equals
### suite: java-security-and-quality.qls, --build-mode=none, per-file isolated databases
### extraction JDK: openjdk version "21.0.11" 2026-04-21 LTS
--- SEED -- expected: query fires (seed/)
"Equals method does not inspect argument type","An implementation of 'equals' that does not check the type of
--- VARIANT -- expected: query fires, actual: not reported (the bug) (variant/)
(query reported nothing)
As noted in MissingInstanceofInEquals.ql , this is an intentional trade-off to keep precision high. When the equals parameter is passed to a library method whose source isn't in the database, we conservatively assume that method may handle the type check rather than risk false positives across external helper methods.
Activity
sam-robson commentedon Nov 3, 2026
Hi @MarkLee131, thanks for the detailed report. We'll take a look into this and follow up.
sam-robson commentedon Nov 3, 2026
As noted in MissingInstanceofInEquals.ql , this is an intentional trade-off to keep precision high. When the equals parameter is passed to a library method whose source isn't in the database, we conservatively assume that method may handle the type check rather than risk false positives across external helper methods.