0

I recently discovered that class ProcessBuilder in JDK6 does not override equals(). Is there a reason? Since the class is mutable, I can understand why it does not override hashCode().

I was surprised to see this code not work:

ProcessBuilder x = new ProcessBuilder("abc", "def");
ProcessBuilder y = new ProcessBuilder("abc", "def");
if (x.equals(y)) {  // they are never equal
    // something important here
}

I looked into the JDK6 source code for class ProcessBuilder, and I do not see an override for equals().

I have a feeling there is a deeper reason, beyond this one class. Perhaps this is intentional?

kevinarpe
  • 20,319
  • 26
  • 127
  • 154

2 Answers2

1

It is considered best practice to make mutable objects not equal unless they are the same object. This is because the object could change later. Consider the following

Set<ProcessBuilder> pbSet = new HashSet<>();
pbSet.add(x);
pbSet.add(y);
// if x and y were equal pbSet would have one element.
y.setSomething()
// should pbSet have one or two elements.

Worse than this is the opposite case where two object could be different but later made the same. This means the Set would have a duplicate object.

What is interesting is that collections are mutable but still have equals and hashCode. I think the reason this is the case is that there is no immutable collections. e.g. String override equals(), StringBuilder does not.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • Even if there were immutable collections, it does not change the fact that if this collection's elements are mutable, you are doomed anyway... But at least, you have _some_ guarantee of a sane equals/hashCode implementation. I have just fixed a bug in a pet project of mine: see [here](https://github.com/fge/abic/commit/43102fbc46da0f6042452541f4a3b9cdcd60cbaa) – fge Jul 07 '13 at 16:35
  • @Peter: That is a fascinating snippet of code. I had never considered this scenario. – kevinarpe Jul 07 '13 at 17:10
1

To complement @PeterLawrey's answer: for objects which are mutable by nature, implementing equals and hashcode is risky in any event. You have no guarantee that such objects are safely published at all. It therefore makes sense that the authors of such classes just "gave up" on equals and hashcode for such classes.

HOWEVER: if you are reasonably sure that you can control this equality, there is something for you: Guava's Equivalence. If you can ensure sufficiently controlled access to highly mutable classes, this allows you to define an equals/hashcode strategy for such objects so that you can even use them in, say, a HashSet.

More about this Equivalence: for an "unstable" class X which is mutable by nature, but for which you can guarantee equivalence in a given context, you implement an Equivalence<X>. Then you "wrap" these instances of X into, for instance, a:

Set<Equivalence.Wrapper<X>>

You'll then add to this set using:

set.add(eq.wrap(x));

where eq is your implementation of an Equivalence.

fge
  • 119,121
  • 33
  • 254
  • 329
  • Great comments and much to consider. Follow-up: Why does the (mutable) collection `ArrayList` implement `equals` and `hashCode`? I am guessing all (mutable) JDK collections do the same. – kevinarpe Jul 07 '13 at 17:13
  • Well, at some point, you have to trust the user; as such, the collections API (including `Map` even though it is not a collection per se) defines `.equals()` and `.hashCode()`, relying on the elements' `.equals()` and `.hashCode()`. Some classes in the JDK are safe to use, for instance, as keys in a `Map` since they are final; as to user defined classes, the user must take responsibility. – fge Jul 07 '13 at 17:20