Question

It’s clear that equals() (and of course hashCode()) are valuable when you’re dealing with immutable value objects — map keys, strongly typed field values that you need to compare across the objects that contain them, etc.

But apart from value objects, how often is it really likely that you’ll have two independently constructed instances and want them to be equal?

It’s hard for me to imagine a realistic scenario where referential equality wouldn’t, de facto, get you what you want; and in those specific cases, it seems like a scenario-specific equivalence method (isEquivalentTo(Foo) rather than equals(Object)) would be safer. Particularly for mutable objects?

What’s the use case for equals() in non-value types?

Answer 1

Um. Set<E> is mutable, and has a (useful) definition of equals(). That doesn’t seem useless…