The document discusses general contracts that must be obeyed when overriding common Object class methods like equals(), hashCode(), toString(), clone(), and implementing the Comparable interface. It emphasizes that failing to follow the contracts can cause dependent classes to malfunction. Specifically, it provides guidance on properly implementing each method while maintaining their expected behaviors and relationships.

1. MANISH ADLAKHA

2.  All methods of Object class have explicit general
contracts because they are meant to be overridden.
 When a class overrides these methods, the contracts
must be obeyed otherwise the classes dependent on
these contracts will not function properly.
 Methods of object class
• equals()
• hashCode()
• toString()
• clone()
• finalize()

3. Obey the general contract when overriding
equals

4.  When a class has a notion of logical equality
which extends mere object identity
 And the behavior is not by a superclass
 Need to find whether they are logically
equivalent and not whether they refer to
same object
 Allows instances to serve as map keys and
show set behavior

5. Equivalence relation
 Reflexive – x.equals(x) -> true
 Symmetric –
x.equals(y) -> true => y.equals(x) -> true
 Transitive
 Consistent -> should return same values
consistently when equals is called
 For a not-null reference, x.equals(null) ->
false

6.  Use the == operator to check if the argument is
a reference to this object
 Use the instanceof operator to check if the
argument has the correct type
 Cast the argument to the correct type
 For each significant field in the class, check if
that field of the argument matches the
corresponding field of this object
 When you are finished writing, ask yourself three
questions:
• Is it symmetric?
• Is it transitive?
• Is it consistent?

7. Always override hashCode when you override
equals

8.  You must override hashCode in every
class that overrides equals.
 Failure to do so results in violation of the general
contract for Object.hashCode, which prevents the class
from functioning properly in conjunction with all hash-
based collections, including HashMap, HashSet, and
Hashtable.

9.  When invoked on an object more than once, hashCode() must
consistently return the same integer, provided no information
used in equals comparisons on the object is modified
 If two objects are equal according to the equals(Object)
method, then calling the hashCode method on each of the
two objects must produce the same integer result.
 Not necessary that hashCode() called on two unequal objects
return distinct hashcode numbers but doing so improves the
performance of hashtables.

10.  The key provision that is violated when you fail to override
hashCode is the second one: equal objects must have equal
hash codes.
 We may exclude redundant fields from the hashCode
computation.
 Do not be tempted to exclude significant parts of an object
from the hash code computation to improve performance.

11. Always override toString()

12.  Default return - class name followed by an “at” sign
(@) and the unsigned hexadecimal representation
of the hash code, for example,
“PhoneNumber@163b91
 General contract
• returned string should be “a concise but informative
representation that is easy for a person to read”

13.  providing a good toString() implementation makes your class
much more pleasant to use.
 toString() invoked when an object is
◦ Passed to println() and printf()
◦ Used in string concatenation operator or assert
◦ Printed by the debugger
 When practical, the toString method should return all of the
interesting information contained in the object
 Whether or not you decide to specify the format, you should
clearly document your intentions
 provide programmatic access to all of the information
contained in the value returned by toString()

14. Override clone() judiciously

15.  A flag interface that advertises that an object permits cloning
 Lacks a clone() method
 Object class’ clone() is protected -> so cannot be used
without using reflection
 Cloneable interface determines the behavior of Object’s
clone() implementation
 It modifies the behavior of a protected method on a
superclass

16.  x.clone() !=x
 x.clone().getclass() == x.getclass()
 x.clone().equals(x) should be true but it is not an
absolute requirement
 No constructors are to be called when creating a
clone

17.  If you override the clone method in a nonfinal class, you
should return an object obtained by invoking super.clone().
 In practice, a class that implements Cloneable is expected to
provide a properly functioning public clone method.
 In effect, the clone method should function as another
constructor; you must ensure that it does no harm to the
original object and that it properly establishes invariants on
the clone
 The clone architecture is incompatible with normal use of
final fields referring to mutable objects

18. Consider implementing Comparable

19.  Method of the comparable interface
 Not declared in Object class
 Allows order comparison along with equality comparisons
 Indicates a natural ordering of instances of a class

20.  sgn(x.compareTo(y)) == -sgn(y.compareTo(x)) for all x and y
 (x.compareTo(y) > 0 && y.compareTo(z) > 0) implies
x.compareTo(z) > 0
 x.compareTo(y) == 0 implies that
sgn(x.compareTo(z)) == sgn(y.compareTo(z)), for all z
 (x.compareTo(y) == 0) == (x.equals(y)) – Strongly
recommended but not strictly required

21.  Violating the compareTo() contract breaks the
classes dependent on comparison
◦ Sorted collections – TreeSet and TreeMap
◦ Utility classes collections and Arrays