7

Class HashMap implements Map interface :

public class HashMap<K,V> extends AbstractMap<K,V>
implements Map<K,V>, Cloneable, Serializable

Class LinkedHashMap extends HashMap that means it should implement Map interface by default. Why is it explicitly implementing Map interface?

public class LinkedHashMap<K,V>
extends HashMap<K,V>
implements Map<K,V>
Shobhit_Geek
  • 591
  • 9
  • 22

4 Answers4

5

You are right: dropping Map<K,V> from linked hash map's declaration would not change anything. Although LinkedHashMap<K,V> would implement Map<K,V> simply because it extends HashMap<K,V>, the fact that linked hash map derives from a regular hash map is an implementation detail, not a hard requirement.

Implementing the Map<K,V> interface, on the other hand, is a fundamental requirement. This requirement would not disappear if the designers decided to implement LinkedHashMap<K,V> from scratch, or to rely on some other base class, e.g. a linked list.

That is why the designers of LinkedHashMap<K,V> mentioned Map<K,V> explicitly: if at some later day a base class would change due to redesign, the interface would stay in place.

Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
4

Well, it is probably for the sake of clarity in the documentation, it adds nothing to the code. It might also be because LinkedHashMap extends HashMap is an implementation detail, what is really important to know is that LinkedHashMap is a Map.

Dici
  • 25,226
  • 7
  • 41
  • 82
3

Practically there is no difference. In my opinion, it was always the case in the JDK classes (the same pattern exists for List and its subclasses). The designers probably still haven't removed this redundant implementation so that nothing breaks in case for example someone relies on reflection to get information about the subtypes. For instance imagine you define the following:

class MyCustomMap<K, V> extends LinkedHashMap<K, V> implements Map<K, V> {

}

Then the below snippet outputs different results with and without the implements:

Class<?>[] interfaces = MyCustomMap.class.getInterfaces();
for (int i = 0; i < interfaces.length; i++) {
    System.out.println(interfaces[i]);
}

Output:

interface java.util.Map

Changing the definition to:

class MyCustomMap<K, V> extends LinkedHashMap<K, V> {

}

then no interface would be printed.

M A
  • 71,713
  • 13
  • 134
  • 174
  • Interesting idea, but did you try the same without the `implements Map` ? You can simulate this easily – Dici May 01 '15 at 11:58
  • @Dici Without the `implements`, no interface is shown in the output. – M A May 01 '15 at 12:02
  • 1
    Mm, if somebody is using reflection that way, it is really a mistake in the first place. Generally we should do something like `for (Class> c = C.class; c != Object.class; c = c.getSuperclass()) {...}`. If Map were implemented for this reason, then it would be for someone relying on *improper* use of `getInterfaces`. – Radiodef May 02 '15 at 12:20
  • 2
    @Radiodef I agree with you. Ideally, Dici's explanation is more convincing. My point is to show a code-wise difference between the two versions. – M A May 02 '15 at 12:24
1

Dici has it right, for the most part.

A long time ago, some of the lesser Java compilers could get a bit confused, and occasionally I added (to my code) interfaces that should have been derived from the parent hierarchy. Perhaps that had a hand in putting the interface in multiple places too (for the Java libraries) but that is pure speculation.

Edwin Buck
  • 69,361
  • 7
  • 100
  • 138