Documentation Preview

Compared to main:
This changeset changes 0 violations,
introduces 0 new violations, 0 new errors and 0 new configuration errors,
removes 0 violations, 25 errors and 8 configuration errors.

Regression Tester Report

(comment created at 2025-08-26 13:25:55+00:00 for f6fddb3)

At first I thought the violations in openjdk-11 (from the regression test) were openjdk doing strange things. Now I had a closer look and it was indeed something I missed.

@UncleOwen this is really cool. I remember back in the day Findbugs used to have a similar rule…

I really like having this here. And certainly the work we did on type res in PMD 7 now makes it significantly easier to manage. Thanks for the PR!

The one thing I don't really like is the name… we should aim for rule names to be as self-descriptive as possible (within a constrained length), and ThatCantBeHere is applicable to any code that is incorrectly placed 😆 Also, without apostrophes, "cant" feels weird in a rule name.

Maybe a better name would explicitly mention collections and types… such as "CollectionTypeMismatch" or something along those lines…

Yes, please consider all my naming open for diskussion :) I'll wait a day or two if someone comes up with other naming ideas, but CollectionTypeMismatch is definitely better than my idea.

I just looked it up, in Findbugs this was GC_UNRELATED_TYPES.

We could check the test cases for that rule to ensure we didn't miss anything:

• https://github.com/findbugsproject/findbugs/blob/master/findbugsTestCases/src/java/bugIdeas/Ideas_2011_07_24.java
• https://github.com/findbugsproject/findbugs/blob/master/findbugsTestCases/src/java/bugIdeas/Ideas_2011_07_03.java
• https://github.com/findbugsproject/findbugs/blob/master/findbugsTestCases/src/java/bugIdeas/Ideas_2012_11_19.java
• https://github.com/findbugsproject/findbugs/blob/master/findbugsTestCases/src/java/bugIdeas/Ideas_2011_10_21.java
• https://github.com/findbugsproject/findbugs/blob/master/findbugsTestCases/src/java/sfBugs/Bug3470297a.java
• https://github.com/findbugsproject/findbugs/blob/master/findbugsTestCases/src/java/sfBugs/Bug3470297.java

Interesting. I didn't think about the collection.equals(anothercollection) case.

I've added the tests from findbugs and made some minor additions because of that. Rule is renamed to CollectionTypeMismatch.

I don't think I want to add support for the collection.equals(anothercollection) case right now, because

1. It's out-of-scope as defined by the ticket.
2. I think it requires different logic than the existing cases, and the rule is already complex as it is.
3. I'm not sure, if that case is a real-life concern. If it is, we can add it if a user requests it.
4. collection.equals(anothercollection) might be a better fit for another (hypothetical?) rule: Do we have something like EqualsOnIncompatibleTypes?

I like the new name of the rule and I think you're right @UncleOwen to not include the pattern collection.equals(anothercollection) in this rule, as this might as well be a new rule that applies to any type, not just collections.

I was thinking there may be a better approach than implementing a new "compatibility" routine in this rule, one that would account for the generic cases you mention are hard.

The notion of "compatibility" we want here is, given types A and B, they are compatible if there is there may be some type C that is a subtype of both A and B. The simplest way to test for this and account for all corner cases related to generics is to treat that as a type inference problem. We can create an inference variable, add two constraints saying that it must subclass A and subclass B, and then solve for the variable. If A and B are incompatible, inference will fail.

I have implemented this approach locally and it works well. I am happy to merge this PR as is into main and propose my changes as a follow-up PR.

@oowekyala Yes, if this can be simplified/generalized/improved in any way, please do so!