Map and Set

[jose chiramal]

I just saw in the api that java.util.Map and Set have equals and hashcode method.

Since HashSet implements Set and even HashMap implements Map shouldnt HashSet and HashMap also have equals method ??

Please help me understand this.

[Rob Spoor]

Every class has these methods; they are inherited from java.lang.Object. However, the Set and Map interfaces specify additional requirements, that's why these methods are in these interfaces. Now you are right that HashSet and HashMap do not override equals. However, both have a superclass that does - AbstractSet and AbstractMap.

[jose chiramal]

Also on what basis does a particular class override equals() or hashcode() methods.

For example I searched the api and i got this :
Arrays overload equals() method
ArrayList doesnt override equals() or hashcode() methods
LinkedList doesnt override equals() or hashcode() methods
Vector overrides equals and hashcode() methods
Stack doesnt override equals() or hashcode() methods

HashTable overrides equls and hashcode() methods
Map overrides equals() method
HashMap doesnt override equals method
LinkedHashMap doesnt override equals method

SortedMap doesnt override equals method
TreeMap doesnt override equals method


Set overrides equals() method
HashSet doesnt override equals method
LinkedHashSet doesnt override equals method

SortedSet doesnt override equals method
TreeSet doesnt override equals method

[Rob Spoor]

jose chiramal wrote:Also on what basis does a particular class override equals() or hashcode() methods.

A class overrides those methods if it needs to. It's as simple as that.

Arrays overload equals() method

Arrays is a utility method. You cannot create instances so there is no need to check for equality. It has overloaded equals to check if two arrays are equal. This is needed because equals for an array uses ==, not content equality.

ArrayList doesnt override equals() or hashcode() methods
LinkedList doesnt override equals() or hashcode() methods
Vector overrides equals and hashcode() methods
Stack doesnt override equals() or hashcode() methods

ArrayList and LinkedList (indirectly) both extend AbstractList which does override both. Apparently that implementation is good enough for ArrayList and LinkedList.
Vector is a synchronized class but AbstractList isn't. Therefore, Vector overrides these two methods only to make them synchronized like the rest of the class. These are their implementations at present:

    public synchronized boolean equals(Object o) {
        return super.equals(o);
    }

    /**
     * Returns the hash code value for this Vector.
     */
    public synchronized int hashCode() {
        return super.hashCode();
    }

    /**
     * Returns a string representation of this Vector, containing
     * the String representation of each element.
     */
    public synchronized String toString() {
        return super.toString();
    }

Like I said, it only adds synchronization, nothing else.

HashTable overrides equls and hashcode() methods
Map overrides equals() method
HashMap doesnt override equals method
LinkedHashMap doesnt override equals method

Map overrides equals method only to specify that map equality means having the same mappings. It makes the contract for the method stricter, nothing more.
Hashtable (with t, not T) does not extend AbstractMap but Dictionary. Dictionary does not override equals. Therefore Hashtable needs to do so to stick to the contract of Map.equals.
HashMap and LinkedHashMap (indirectly) both extend AbstractHashMap which implements equals, in a way that is good enough for these two classes.

SortedMap doesnt override equals method
TreeMap doesnt override equals method

SortedMap inherits the contract on equals from Map. TreeMap inherits the implementation from AbstractMap.

Set overrides equals() method
HashSet doesnt override equals method
LinkedHashSet doesnt override equals method

SortedSet doesnt override equals method
TreeSet doesnt override equals method

See my story about Map.


Summarizing, if the implementation of the super class is good enough there is no need to override equals. With the List, Set and Map implementations the abstract implementations (AbstractList, AbstractSet, AbstractMap) have default implementations that are good enough for most concrete implementations.

[jose chiramal]

Thanks Bob Prime for your response.

One question, since Vector is synchronised why doesnt the api have the methods under them with the synchornised keyword before the return type..

[Christophe Verré]

From What's new in Javadoc 1.2 :

Remove "synchronized" and "native" from signatures. Javadoc generates an API specification. These two keywords do not belong in the signatures of a specification, because they are implementation-specific. The keyword "native" does not need to be documented. The keyword "synchronized" indicates thread-safe behavior that should instead be described in the method descriptions. A thread-safe method itself might not use the "synchronized" keyword but might call private methods that are.
Old Behavior: Javadoc 1.1 includes the keywords "synchronized" and "native".