Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MutableStateFieldCheck: "equalsChanged" misleading #315

Closed
C-Otto opened this issue Jun 1, 2020 · 3 comments
Closed

MutableStateFieldCheck: "equalsChanged" misleading #315

C-Otto opened this issue Jun 1, 2020 · 3 comments
Labels

Comments

@C-Otto
Copy link

C-Otto commented Jun 1, 2020

Up front: I'm dealing with legacy code, which is why my bug report might be a bit esoteric. This popped up when I replaced old/broken code by EqualsVerifier to check another (very simple) exception class.

What steps will reproduce the problem?

EqualsVerifier.configure()
                .suppress(INHERITED_DIRECTLY_FROM_OBJECT)
                .forClass(NullPointerException.class)
                .usingGetClass()
                .verify();

Note: NullPointerException does not override equals, as such the default == implementation in Object is used.

What is the code that triggers this problem?

MutableStateFieldCheck.execute does not check if the two objects were equal before the mutation. The boolean equalsChanged is wrong in the sense that, in this case, the two instances were not equal before the change, and still are not equal after the change.

What error message or stack trace does EqualsVerifier give?

java.lang.AssertionError: EqualsVerifier found a problem in class NullPointerException.
-> Mutability: equals depends on mutable field detailMessage.

What did you expect?

Test passes

Which version of EqualsVerifier are you using?

3.1.12

Please provide any additional information below.

Thank you for the awesome project!

@jqno
Copy link
Owner

jqno commented Jun 2, 2020

Thanks for reporting this, and thanks for the nice words!

I can reproduce the issue as you report it. I agree that this is a bug in EqualsVerifier, and at the moment I can't offer a good workaround.

You have a good point that assuming that the two objects are equal before the mutation may not be correct; however, if I make changes based on your suggestions, a whole bunch of other test cases break. I'll have to investigate further. I'll let you know when I have a solution. I can't make any promises about when that will be. I do accept PR's however :)

@jqno jqno added the accepted label Jun 2, 2020
@C-Otto
Copy link
Author

C-Otto commented Jun 2, 2020

Thanks. I don't need a quick fix. I can make use of ClassAccessor.isEqualsInheritedFromObject to skip the equals verification. Besides, this part of the project is on hold for now due to bigger issues with the code.

@jqno
Copy link
Owner

jqno commented Jun 13, 2020

I've just released version 3.4, which fixes this. You'll still need to suppress some Warnings, though. Check out this unit test.

@jqno jqno closed this as completed Jun 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants