Effective Java

Don’t provide a detailed specification for the value returned by 
hashCode
,
so clients can’t reasonably depend on it; this gives you the flexibility to
change it.
Many classes in the Java libraries, such as 
String
and 
Integer
, specify
the exact value returned by their 
hashCode
method as a function of the instance
value. This is 
not
a good idea but a mistake that we’re forced to live with: It
impedes the ability to improve the hash function in future releases. If you leave
the details unspecified and a flaw is found in the hash function or a better hash
function is discovered, you can change it in a subsequent release.
In summary, you 
must
override 
hashCode
every time you override 
equals
, or
your program will not run correctly. Your 
hashCode
method must obey the general
contract specified in 
Object
and must do a reasonable job assigning unequal hash
codes to unequal instances. This is easy to achieve, if slightly tedious, using the
recipe on page 51. As mentioned in Item 10, the AutoValue framework provides a
fine alternative to writing 
equals
and 
hashCode
methods manually, and IDEs also
provide some of this functionality.

---

ITEM 12: ALWAYS OVERRIDE TOSTRING
55
Item 12: Always override 
toString
While 
Object
provides an implementation of the 
toString
method, the string that
it returns is generally not what the user of your class wants to see. It consists of the
class name followed by an “at” sign (
@
) and the unsigned hexadecimal representa-
tion of the hash code, for example, 
PhoneNumber@163b91
. The general contract for
toString
says that the returned string should be “a concise but informative repre-
sentation that is easy for a person to read.” While it could be argued that
PhoneNumber@163b91
is concise and easy to read, it isn’t very informative when
compared to 
707-867-5309
. The 
toString
contract goes on to say, “It is recom-
mended that all subclasses override this method.” Good advice, indeed!
While it isn’t as critical as obeying the 
equals
and 
hashCode
contracts (Items
10 and 11),