Possible regression w.r.t. reflexivity.

[GoogleCodeExporter]

Consider the code below:

    public final class DummyClass {
        @Override
        public boolean equals(final Object other) {
            return super.equals(other);
        }

        @Override
        public int hashCode() {
            return super.hashCode();
        }
    }

    @Test
    public void dummyTest() {
        EqualsVerifier.forClass(DummyClass.class).verify();
    }

With EqualsVerifier 1.0.2 the test passes. With EqualsVerifier 1.1 the test 
fails, stating:

    java.lang.AssertionError: Reflexivity: object does not equal an identical copy of itself

When the overridden #equals(Object) and #hashCode() methods are removed the 
test passes with both version 1.0.2 and 1.1.

Admittedly overriding the methods as shown above is not useful, but 
nevertheless the error message seems misleading at best. Java's default 
implementation of #equals(Object) _is_ reflexive. The semantics of the default 
implementation of #equals(Object) simply state that there cannot be an 
"identical copy" of the object.

I haven't looked at the code, but looking at the release notes, it seems likely 
that this change in behavior is related to Issue 53...

Original issue reported on code.google.com by [email protected] on 12 Feb 2012 at 9:12

[GoogleCodeExporter]

Hi Stephan,

First of all, I apologize for the late reply. And thanks for the bug report.

You're right, this is a regression; however it's not related to Issue 53, but 
to Issue 55. Turns out it was possible to cast to a completely unrelated class 
inside the equals method, and still make EqualsVerifier pass. Take a look at 
this test, to see what I mean: 
http://code.google.com/p/equalsverifier/source/diff?spec=svn345&r=345&format=sid
e&path=/trunk/test/nl/jqno/equalsverifier/ReflexivityTest.java

I still believe it's useful to test for this, and to be honest, I was seriously 
thinking of rejecting this issue, when I ran into a use case for this myself, 
where I had a hierarchy of classes, and one of those classes needed to be 
singleton, as a sort of Null Object Pattern.

So, what I will do instead, is add a new Warning that can be suppressed. This 
way, you can add #suppress(Warning.IDENTICAL_COPY) to your call to 
EqualsVerifier, and this class will pass. If you decide to change the class 
later on, and identical copies do become equal, EqualsVerifier will fail and 
tell you to remove the call again.

I've already made a fix for this, but I want to think about this a little bit 
longer. If I don't change my mind, I'll release it in the next few days or so.

Just out of curiosity though, what was your use case when you found this issue?

Original comment by [email protected] on 19 Feb 2012 at 10:13

• Changed state: Accepted
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I did not have a good use case. All other classes in the package did have 
custom #equals and #hashCode methods, along with an EqualsVerifier unit test. 
For consistency I did the same for this new class, assuming that I'd come up 
with something better later on. For now I have simply deleted the methods; I'll 
probably not reinstate them.

B.t.w, I do like the proposed solution :)

Original comment by [email protected] on 19 Feb 2012 at 10:23

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Hi Stephan,

So that's how you found this :).
Anyway, I just released version 1.1.1, so you can now reinstate your equals 
methods if you like :).

Jan

Original comment by [email protected] on 21 Feb 2012 at 10:20

• Changed state: Fixed
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

if equals() or hashcode() check is performed on enums, the verification fails. 
As we know that a custom Enum in java which extends from java.lang.Enum does 
not override equals().

So if I have a list of classes against which the check needs to be done, I have 
to ignore enums or call 'suppress(Warning.IDENTICAL_COPY)'

Original comment by [email protected] on 12 Jul 2012 at 2:24

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Hi Raghavan,

EqualsVerifier is meant to test classes that override equals. Enums, as you 
already said, don't. In fact, it would be a compile error if you tried to.

Why are these enums included in your list of classes that should be checked 
with EqualsVerifier? Because I don't think they should be.


Regards,
Jan

Original comment by [email protected] on 13 Jul 2012 at 8:32

• Added labels: ****
• Removed labels: ****