Java: Only check hashCode in equals() of immutable object

Question

I have an immutable object, for example a node in the Cartesian space. The class is immutable, so I cache the hashCode for very fast hashing.

private final int hashCode;

private final double x, y, z;

public Node(final double x, final double y, final double z)
{
    this.x = x;
    this.y = y;
    this.z = z;
    this.hashCode = Objects.hashCode(this.x, this.y, this.z);
}

@Override
public boolean equals(final Object obj)
{
    if (this == obj) { return true; }
    if (obj == null) { return false; }
    if (!(obj instanceof Node)) { return false; }
    final Node other = (Node) obj;
    return Objects.equal(this.x, other.x) && Objects.equal(this.y, other.y) && Objects.equal(this.z, other.z);
}

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

Since the hashCode is unique and dependent on all fields of the class AND the class is Immutable, would it be correct to only check Node equality based on the hashCode?

@Override
public boolean equals(final Object obj)
{
    if (this == obj) { return true; }
    if (obj == null) { return false; }
    if (!(obj instanceof Node)) { return false; }
    final Node other = (Node) obj;
    return this.hashCode == other.hashCode;
}

This passes all Unit Tests I have written about the properties of equals() and hashCode() and their interaction, but perhaps there is something I am missing?

Note: Objects.hashCode() and Objects.equal() are Guava classes helpful for the respective methods.

@SLaks You're right, thanks. **Hashcodes are not unique**. Also thanks for the tip about the redundant null check :). — Alexander Karatarakis, Apr 18 '12 at 00:33
For reference, as also mentioned here: http://stackoverflow.com/a/7417858/713659 , you can check for hashCode first before going into more expensive equality checks, but you cannot skip other checks. — Alexander Karatarakis, Apr 18 '12 at 00:36
FYI, there's no need to use `Objects.equal` in the `equals` implementation, since you're comparing primitives. `==` will be faster and simpler. — Louis Wasserman, Apr 18 '12 at 00:50
@LouisWasserman I used it to compare the hashCode which is an int, but won't it be a problem when comparing doubles? — Alexander Karatarakis, Apr 18 '12 at 01:03

score 17 · Accepted Answer · answered Apr 18 '12 at 00:24

17

Nope; that won't work.

You have 2³² possible hashcodes and 2¹⁹² possible values.

answered Apr 18 '12 at 00:24

SLaks

868,454
176
1,908
1,964

score 2 · Answer 2 · answered Sep 05 '12 at 18:10

No, but..

I guess you could check the hashcode to see whether objects are not equal and gain some performance there:

public boolean equals(final Object obj) {
   if (this == obj) { return true; }
   if (!(obj instanceof Node)) { return false; }
   final Node other = (Node) obj;

   if (this.hashCode != other.hashCode) {
      return false; // If hashcodes differ, we're sure the objects are not equal
   }
   // remainder of the actual equals implementation
}

Of course this will only improve performance in case most of your comparisons yield false. In case of equal objects, this will bring a performance penalty. In your example (comparing just three values), I wouldn't recommend this.

Java: Only check hashCode in equals() of immutable object

2 Answers2