What is the difference between the HashMap and Map objects in Java

Question

What is the difference between the following maps I create  in another question  people answered using them seemingly interchangeably and I m wondering if how they are different    HashMap lt String  Object gt  map   new HashMap lt String  Object gt     Map lt String  Object gt  map   new HashMap lt String  Object gt

User · Answer

HashMap is an implementation of Map so it s quite the same but has  clone    method as i see in reference guide

User · Answer

Map is the Interface and Hashmap is the class that implements that    So in this implementation you create the same objects

User · Answer

Map has the following implementations    HashMap    Map m   new HashMap    LinkedHashMap     Map m   new LinkedHashMap    Tree Map     Map m   new TreeMap    WeakHashMap    Map m   new WeakHashMap      Suppose you have created one method  this is just pseudocode     public void HashMap getMap       return map      Suppose your project requirements change      The method should return map contents - Need to return HashMap      The method should return map key s in insertion order - Need to change return type HashMap to LinkedHashMap       The method should return map key s in sorted order - Need to change return type LinkedHashMap to TreeMap         If your method returns specific classes instead of something that implements the Map interface  you have to change the return type of getMap   method each time    But if you use the polymorphism feature of Java  and instead of returning specific classes  use the interface Map  it improves code reusability and reduces the impact of requirement changes

User · Answer

Map is an interface that HashMap implements   The difference is that in the second implementation your reference to the HashMap will only allow the use of functions defined in the Map interface  while the first will allow the use of any public functions in HashMap  which includes the Map interface    It will probably make more sense if you read Sun s interface tutorial

User · Answer

As noted by TJ Crowder and Adamski  one reference is to an interface  the other to a specific implementation of the interface   According to Joshua Block  you should always attempt to code to interfaces  to allow you to better handle changes to underlying implementation - i e  if HashMap suddenly was not ideal for your solution and you needed to change the map implementation  you could still use the Map interface  and change the instantiation type

User · Answer

Map is the static type of map  while HashMap is the dynamic type of map  This means that the compiler will treat your map object as being one of type Map  even though at runtime  it may point to any subtype of it   This practice of programming against interfaces instead of implementations has the added benefit of remaining flexible  You can for instance replace the dynamic type of map at runtime  as long as it is a subtype of Map  e g  LinkedHashMap   and change the map s behavior on the fly   A good rule of thumb is to remain as abstract as possible on the API level  If for instance a method you are programming must work on maps  then it s sufficient to declare a parameter as Map instead of the stricter  because less abstract  HashMap type  That way  the consumer of your API can be flexible about what kind of Map implementation they want to pass to your method

User · Answer

Adding to the top voted answer and many ones above stressing the  more generic  better   I would like to dig a little bit more   Map is the structure contract while HashMap is an implementation providing its own methods to deal with different real problems  how to calculate index  what is the capacity and how to increment it  how to insert  how to keep the index unique  etc   Let s look into the source code   In Map we have the method of containsKey Object key    boolean containsKey Object key     JavaDoc      boolean java util Map containsValue Object value       Returns true if this map maps one or more keys to the specified value  More formally  returns true if and only if this map contains at least one mapping to a value v such that  value  null   v  null   value equals v    This operation will probably require time linear in the map size for most implementations of the Map interface       Parameters value      value whose presence in this map is to betested      Returns true       if this map maps one or more keys to the specified      valueThrows       ClassCastException - if the value is of an inappropriate type for this map  optional       NullPointerException - if the specified value is null and this map does not permit null values  optional    It requires its implementations to implement it  but the  how to  is at its freedom  only to ensure it returns correct   In HashMap   public boolean containsKey Object key        return getNode hash key   key     null      It turns out that HashMap uses hashcode to test if this map contains the key  So it has the benefit of hash algorithm

User · Answer

I was just going to do this as a comment on the accepted answer but it got too funky  I hate not having line breaks      ah  so the difference is that in   general  Map has certain methods   associated with it  but there are   different ways or creating a map  such   as a HashMap  and these different ways   provide unique methods that not all   maps have    Exactly--and you always want to use the most general interface you possibly can   Consider ArrayList vs LinkedList   Huge difference in how you use them  but if you use  List  you can switch between them readily     In fact  you can replace the right-hand side of the initializer with a more dynamic statement   how about something like this   List collection  if keepSorted      collection new LinkedList    else     collection new ArrayList      This way if you are going to fill in the collection with an insertion sort  you would use a linked list  an insertion sort into an array list is criminal    But if you don t need to keep it sorted and are just appending  you use an ArrayList  More efficient for other operations    This is a pretty big stretch here because collections aren t the best example  but in OO design one of the most important concepts is using the interface facade to access different objects with the exact same code   Edit responding to comment   As for your map comment below  Yes using the  Map  interface restricts you to only those methods unless you cast the collection back from Map to HashMap  which COMPLETELY defeats the purpose    Often what you will do is create an object and fill it in using it s specific type  HashMap   in some kind of  create  or  initialize  method  but that method will return a  Map  that doesn t need to be manipulated as a HashMap any more   If you ever have to cast by the way  you are probably using the wrong interface or your code isn t structured well enough   Note that it is acceptable to have one section of your code treat it as a  HashMap  while the other treats it as a  Map   but this should flow  down   so that you are never casting   Also notice the semi-neat aspect of roles indicated by interfaces   A LinkedList makes a good stack or queue  an ArrayList makes a good stack but a horrific queue  again  a remove would cause a shift of the entire list  so LinkedList implements the Queue interface  ArrayList does not

User · Answer

HashMap lt String  Object gt  map1   new HashMap lt String  Object gt     Map lt String  Object gt  map2   new HashMap lt String  Object gt         First of all Map is an interface it has different implementation like - HashMap  TreeHashMap  LinkedHashMap etc  Interface works like a super class for the implementing class  So according to OOP s rule any concrete class that implements Map is a Map also  That means we can assign put any HashMap type variable to a Map type variable without any type of casting    In this case we can assign map1 to map2 without any casting or any losing of data -    map2   map1

User · Answer

You create the same maps   But you can fill the difference when you will use it  With first case you ll be able to use special HashMap methods  but I don t remember anyone realy useful   and you ll be able to pass it as a HashMap parameter   public void foo  HashMap lt String  Object                HashMap lt String  Object gt  m1        Map lt String  Object gt  m2         foo  m1   foo   HashMap lt String  Object gt  m2

User · Answer

There is no difference between the objects  you have a HashMap lt String  Object gt  in both cases  There is a difference in the interface you have to the object  In the first case  the interface is HashMap lt String  Object gt   whereas in the second it s Map lt String  Object gt   But the underlying object is the same   The advantage to using Map lt String  Object gt  is that you can change the underlying object to be a different kind of map without breaking your contract with any code that s using it  If you declare it as HashMap lt String  Object gt   you have to change your contract if you want to change the underlying implementation     Example  Let s say I write this class   class Foo       private HashMap lt String  Object gt  things      private HashMap lt String  Object gt  moreThings       protected HashMap lt String  Object gt  getThings             return this things             protected HashMap lt String  Object gt  getMoreThings             return this moreThings             public Foo             this things   new HashMap lt String  Object gt             this moreThings   new HashMap lt String  Object gt                      more        The class has a couple of internal maps of string- object which it shares  via accessor methods  with subclasses  Let s say I write it with HashMaps to start with because I think that s the appropriate structure to use when writing the class   Later  Mary writes code subclassing it  She has something she needs to do with both things and moreThings  so naturally she puts that in a common method  and she uses the same type I used on getThings getMoreThings when defining her method   class SpecialFoo extends Foo       private void doSomething HashMap lt String  Object gt  t                              public void whatever             this doSomething this getThings             this doSomething this getMoreThings                      more        Later  I decide that actually  it s better if I use TreeMap instead of HashMap in Foo  I update Foo  changing HashMap to TreeMap  Now  SpecialFoo doesn t compile anymore  because I ve broken the contract  Foo used to say it provided HashMaps  but now it s providing TreeMaps instead  So we have to fix SpecialFoo now  and this kind of thing can ripple through a codebase    Unless I had a really good reason for sharing that my implementation was using a HashMap  and that does happen   what I should have done was declare getThings and getMoreThings as just returning Map lt String  Object gt  without being any more specific than that  In fact  barring a good reason to do something else  even within Foo I should probably declare things and moreThings as Map  not HashMap TreeMap   class Foo       private Map lt String  Object gt  things                  lt    Changed     private Map lt String  Object gt  moreThings              lt    Changed      protected Map lt String  Object gt  getThings             lt    Changed         return this things             protected Map lt String  Object gt  getMoreThings         lt    Changed         return this moreThings             public Foo             this things   new HashMap lt String  Object gt             this moreThings   new HashMap lt String  Object gt                      more        Note how I m now using Map lt String  Object gt  everywhere I can  only being specific when I create the actual objects   If I had done that  then Mary would have done this   class SpecialFoo extends Foo       private void doSomething Map lt String  Object gt  t        lt    Changed                           public void whatever             this doSomething this getThings             this doSomething this getMoreThings                  and changing Foo wouldn t have made SpecialFoo stop compiling   Interfaces  and base classes  let us reveal only as much as is necessary  keeping our flexibility under the covers to make changes as appropriate  In general  we want to have our references be as basic as possible  If we don t need to know it s a HashMap  just call it a Map   This isn t a blind rule  but in general  coding to the most general interface is going to be less brittle than coding to something more specific  If I d remembered that  I wouldn t have created a Foo that set Mary up for failure with SpecialFoo  If Mary had remembered that  then even though I messed up Foo  she would have declared her private method with Map instead of HashMap and my changing Foo s contract wouldn t have impacted her code   Sometimes you can t do that  sometimes you have to be specific  But unless you have a reason to be  err toward the least-specific interface

User · Answer

In your second example the  map  reference is of type Map  which is an interface implemented by HashMap  and other types of Map    This interface is a contract saying that the object maps keys to values and supports various operations  e g  put  get    It says nothing about the implementation of the Map  in this case a HashMap    The second approach is generally preferred as you typically wouldn t want to expose the specific map implementation to methods using the Map or via an API definition

User · Answer

Map is interface and Hashmap is a class that implements Map Interface

[java] What is the difference between the HashMap and Map objects in Java?

Examples related to java

Examples related to dictionary

Examples related to hashmap