If your object is mutable, then it is acceptable to have its hash code change over time. Of course, you should prefer immutable objects (Effective Java 2nd Edition, Item 15: Minimize mutability).
Here's the hashcode recipe from Josh Bloch, from Effective Java 2nd Edition, Item 9: Always override hashCode when you override equals:
Effective Java 2nd Edition hash code recipe
- Store some constant nonzero value, say 17, in an
int variable called result.
- Compute an
int hashcode c for each field:
- If the field is a
boolean, compute (f ? 1 : 0)
- If the field is a
byte, char, short, int, compute (int) f
- If the field is a
long, compute (int) (f ^ (f >>> 32))
- If the field is a
float, compute Float.floatToIntBits(f)
- If the field is a
double, compute Double.doubleToLongBits(f), then hash the resulting long as in above.
- If the field is an object reference and this class's
equals method compares the field by recursively invoking equals, recursively invoke hashCode on the field. If the value of the field is null, return 0.
- If the field is an array, treat it as if each element is a separate field. If every element in an array field is significant, you can use one of the
Arrays.hashCode methods added in release 1.5.
- Combine the hashcode
c into result as follows: result = 31 * result + c;
It would be correct to follow the recipe as is, even with just one field. Just do the appropriate action depending on the type of the field.
Note that there are libraries that actually simplify this for you, e.g. HashCodeBuilder from Apache Commons Lang, or just Arrays.hashCode/deepHashCode from java.util.Arrays.
These libraries allows you to simply write something like this:
@Override public int hashCode() {
return Arrays.hashCode(new Object[] {
field1, field2, field3, //...
});
}
Apache Commons Lang example
Here's a more complete example of using the builders from Apache Commons Lang to facilitate a convenient and readable equals, hashCode, toString, and compareTo:
import org.apache.commons.lang.builder.*;
public class CustomType implements Comparable<CustomType> {
// constructors, etc
// let's say that the "significant" fields are field1, field2, field3
@Override public String toString() {
return new ToStringBuilder(this)
.append("field1", field1)
.append("field2", field2)
.append("field3", field3)
.toString();
}
@Override public boolean equals(Object o) {
if (o == this) { return true; }
if (!(o instanceof CustomType)) { return false; }
CustomType other = (CustomType) o;
return new EqualsBuilder()
.append(this.field1, other.field1)
.append(this.field2, other.field2)
.append(this.field3, other.field3)
.isEquals();
}
@Override public int hashCode() {
return new HashCodeBuilder(17, 37)
.append(field1)
.append(field2)
.append(field3)
.toHashCode();
}
@Override public int compareTo(CustomType other) {
return new CompareToBuilder()
.append(this.field1, other.field1)
.append(this.field2, other.field2)
.append(this.field3, other.field3)
.toComparison();
}
}
These four methods can be notoriously tedious to write, and it can be difficult to ensure that all of the contracts are adhered to, but fortunately libraries can at least help make the job easier. Some IDEs (e.g. Eclipse) can also automatically generate some of these methods for you.
See also
- Apache Commons Lang Builders
- Effective Java 2nd Edition
- Item 8: Obey the general contract when overriding
equals
- Item 9: Always override
hashCode when you override equals
- Item 10: Always override
toString
- Item 12: Consider implementing
Comparable
- Item 2: Consider a builder when faced with many constructor parameters
