Repository navigation
[Bug] Ignored fields still are getting a dataset #1141
Description
Describe the bug
It is related to #1140. Use the same code but ignoring the values field.
EqualsVerifier
.forClass(Pojo.class)
.withIgnoredFields("values")
.verify();It will still fail trying to create some values for the field.
According to me, we do not need to generate any dataset for ignored fields.
It would prevent the failure and bring some speed.
Steps to reproduce
No response
Error message and version number
java.lang.AssertionError: EqualsVerifier found a problem in class pro.tremblay.equalsverifiercheck.Pojo.
-> Collection is empty
Using 4.2.1
Code: EqualsVerifier invocation
No response
Code: class under test
No response
Additional context
No response
Activity
jqno commentedon Nov 7, 2025
Ignoring fields is intended for whether or not fields should participate in the equals contract. EqualsVerifier still needs to be able to instantiate every field, though, whether it's ignored or not, in order to prevent potential NullPointerExceptions.
I agree that this is a confusing point in EqualsVerifier. It has come up several times before, and unfortunately I don't have a good answer for it. What I can do, is improve the Javadoc and the documentation on the website. I'll leave this ticket open until I've done that.
henri-tremblay commentedon Nov 7, 2025
But then, if a field not used in the equals has an issue and can't be ignored, I'm doomed?
jqno commentedon Nov 8, 2025
Maybe I could try to keep these fields
nullby default, and only complain when an NPE is actually encountered (which indeed should not happen in most cases). I'll have to do some research to see if I can make that work.jqno commentedon Nov 15, 2025
So I played around with this a little bit, and there's one aspect that I didn't think about when I wrote my reply, but apparently I did think about it in the test suite.
When you ignore a field, EqualsVerifier wants to make sure that it's actually ignored in your equals and hashCode. If you happen to use it after all, it will throw an error, to prevent masking other errors when a field is set to ignored by accident (or if the design changed over time).
Anyway, in order to do this check, EqualsVerifier needs to give the field a value, which needs to be a valid instance of the type, and if it can't come up with one, it will ask for a prefab value. (Or in the case of your other issue, it will come up with a cryptic error message. Thankfully that one's solved now 😅) So unfortunately we do need data for ignored values after all.
As promised above, I'll improve the Javadoc and the website to make this point clearer (including for future me). I'll leave the ticket open until I've done so.
jqno commentedon Nov 16, 2025
I've added a short paragraph to the Javadoc for
#withIgnoredFields()which will go out the next time I make a release, and I've added an entry to the error messages page on the website here.I also added something to the manual page about ignoring fields and the manual page about prefab values
I've also thought about renaming the
#withIgnoredFields()method to something more clear, but I couldn't think of a way to phrase it that's both clear, and also works as a method name, so I left the name as-is for now. Of course I'm open to suggestions.henri-tremblay commentedon Nov 16, 2025
I think validating that the field is not used is great. It feels more like a framework issue to require a value to perform this validation. But it's true that, on my side, it's all good.
I think
withUnusedFieldscould be a nice name. AndwithIgnoredFieldswould then be a fully ignored field. We would set an ignored field only when there's something wrong with a field and even if it's used or not, we do no want it to be considered.jqno commentedon Nov 17, 2025
If by "framework issue" you mean, it should be an "EqualsVerifier problem" not a "user of EqualsVerifier problem", then yes, I agree with you. But I don't see a good way around it at the moment, unfortunately. It would take a lot of time which I don't have a lot of, and without a guarantee of success. So I'm going to have to leave it at that for now, unfortunately. Maybe at some point in the future I'll be able to revisit.
I'm happy that for your case at least, the problem is now avoided. I like your suggested name, I'll give it some more thought.