The Timestamp class override Object.equals but not Object.hashCode. This violates the restriction that:

a.equals(b) ==> a.hashCode()==b.hashCode()

    Further, the equals function returns false when a Timestamp is compared to
Date objects that are equal from the perspective of the Date class. This is extremely bad! It violates the transitivity restriction on the equals method in a highly visible fashion. It is perhaps questionable that Timestamp extends (rather than encapsulates) Date, but given this design decision, it's imperative that Timestamp does *not* override the equals method. (The only alternative is
to modify the equals method of Date to make it aware of timestamps, but this
is extremely unpalatable.)

If our customers use Timestamp objects as keys in Hashtables or HashMaps, or elements in HashSets, the basic invariants of the collections will be corrupted, leading to erratic behavior.