What is the difference between the HashMap and Map objects in Java?
There is no difference between the objects; you have a HashMap<String, Object>
in both cases. There is a difference in the interface you have to the object. In the first case, the interface is HashMap<String, Object>
, whereas in the second it's Map<String, Object>
. But the underlying object is the same.
The advantage to using Map<String, Object>
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<String, Object>
, 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<String, Object> things;
private HashMap<String, Object> moreThings;
protected HashMap<String, Object> getThings() {
return this.things;
}
protected HashMap<String, Object> getMoreThings() {
return this.moreThings;
}
public Foo() {
this.things = new HashMap<String, Object>();
this.moreThings = new HashMap<String, Object>();
}
// ...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 HashMap
s 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<String, Object> 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 HashMap
s, 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<String, Object>
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<String, Object> things; // <== Changed
private Map<String, Object> moreThings; // <== Changed
protected Map<String, Object> getThings() { // <== Changed
return this.things;
}
protected Map<String, Object> getMoreThings() { // <== Changed
return this.moreThings;
}
public Foo() {
this.things = new HashMap<String, Object>();
this.moreThings = new HashMap<String, Object>();
}
// ...more...
}
Note how I'm now using Map<String, Object>
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<String, Object> t) { // <== 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.
Difference between using Map and HashMap as declared type
There is no underlying difference. It is more about the interface. There's an advantage of using a Map
though, that is you can change the object to be a different kind of a Map
without breaking the contract of the code using it.
The HashMap
is an implementation of Map
, which is part of the Java Collections Framework. If you settle on using the HashMap
and then the other party wishes for something different, like LinkedHashMap
(preserves iteration order), then you have to change things around. Here's a diagram (courtesy ProgramCreek).
There are other things like computational time complexity, if you care about performance. Here's a small table that helps. Choosing the right thing is a question of design and need i.e. what are you trying to do. It varies from project to project.
Hashmap VS Map in Java
There is no difference between the objects. There is a difference in the interface you have to the object. In the first case, the interface is HashMap<String, Object>
, whereas in the second it's Map<String, Object>
. The underlying object, though, is the same.
The advantage to using Map<String, Object>
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<String, Object>
, you have to change your contract if you want to change the underlying implementation...
Also 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..
Difference between HashMap, LinkedHashMap and TreeMap
All three classes implement the Map
interface and offer mostly the same functionality. The most important difference is the order in which iteration through the entries will happen:
HashMap
makes absolutely no guarantees about the iteration order. It can (and will) even change completely when new elements are added.TreeMap
will iterate according to the "natural ordering" of the keys according to theircompareTo()
method (or an externally suppliedComparator
). Additionally, it implements theSortedMap
interface, which contains methods that depend on this sort order.LinkedHashMap
will iterate in the order in which the entries were put into the map
"Hashtable" is the generic name for hash-based maps. In the context of the Java API,Hashtable
is an obsolete class from the days of Java 1.1 before the collections framework existed. It should not be used anymore, because its API is cluttered with obsolete methods that duplicate functionality, and its methods are synchronized (which can decrease performance and is generally useless). Use ConcurrentHashMap instead of Hashtable.
Related Topics
How to Count the Number of Occurrences of an Element in a List
Java - Method Name Collision in Interface Implementation
Get a Resource Using Getresource()
How to Check If the User Is Pressing a Key
How to Import a Class from Default Package
Java "Void" and "Non Void" Constructor
Centering a Jlabel on a JPAnel
Combineddomainxyplot Not Rescaling Domain Axis
Antlr: Is There a Simple Example
How to Import a .Cer Certificate into a Java Keystore
How to Use Java Property Files
Hibernate JPA Sequence (Non-Id)
How to Load a Jar File at Runtime
How to Set the Default Locale in the Jvm
No Compiler Is Provided in This Environment. Perhaps You Are Running on a Jre Rather Than a Jdk