LinkedHashMap signature

Looking at the JDK source code fo开发者_如何学Gor LinkedHashMap, I noticed that this class is declared as:

 public class LinkedHashMap<K,V>
       extends HashMap<K,V>
       implements Map<K,V>
   {...

why the redundant "implements Map<K,V>" (since HashMap already implements Map) ? I cannot imagine this is a typo...

Thanks.

I suppose it's a way of saying

No matter what interfaces HashMap implements (now or in the future), this class should implement the Map interface.

If someone responsible for the HashMap decides that it should no longer implement the Map interface, the compiler will warn the maintainer of LinkedHashMap that it no longer implements the Map interface as he intended.

Of course it's silly in this particular case (HashMap will obviously always be a Map), but similar situations may benefit from (and have given rise to) such convention.

It's ancient code. Up to some point around JDK 1.1.6 or so, Javadoc didn't show inherited interfaces, so it was customary or indeed necessary to reiterate them in derived classes to get the Javadoc to work right. They were introduced in JDK 1.2 but were available well before that as an add-on for 1.1.x.

It is seems like style/code convention: LinkedHashSet has similar signature. Maybe it's just to emphasize interface usage. Compare with c++, where it is good practice to write "virtual" with all virtual functions, even if they are already implicitly virtual .

Could be an error on the part of the coder.

They might also have wanted to make the use of the interface explicit. Since declaring it twice does no harm beyond extra key strokes, I don't have a problem with it.

My guess is to allow LinkedHashMap to provide custom implementation of the methods declared in Map interface. This way it wouldn't inherit all the implementations from HashMap.

It makes the intent clearer, so that it is obvious that this is intended to be a Map implementation, with specific behaviour, which incidentally happens to be created by extending HashMap, thereby being able to be used in some places, in place of a HashMap.