difference between hashmap and hashtable

[TP]

A hashmap is not synchronized and faster than hashtable.

In a servlet application when you have httpsession to take care of
session independance, is there any reason that I should use hashtable
over hashmap?

Thanks.

 

[Anton Spaans]

A hashmap is not synchronized and faster than hashtable.

In a servlet application when you have httpsession to take care of
session independance, is there any reason that I should use hashtable
over hashmap?

Thanks.

Usually not, unless you cache static data that is initialized lazily (i.e.
loaded when it becomes available first, afterwards it is only read, never
updated).

If you do not need any cached data (used by the entire application,
regardless of request/session), there is no real need for hashtable.
If you have cached data that is read on initialization (during the servlet's
init() method), there is no real need for hashtable. In both cases hashmap
is fine.

(this does not deal with any clustering of web-servers and such. I assume
that data can be cached statically)

-- Anton.

 

[Adam Jenkins]

A hashmap is not synchronized and faster than hashtable.

In a servlet application when you have httpsession to take care of
session independance, is there any reason that I should use hashtable
over hashmap?

The Hashtable class was created before the current Collection API was
designed. There's really no reason to ever use Hashtable anymore except
for interacting with existing code which uses a Hashtable. If you need
a synchronized version of HashMap, you can get it by calling

Map syncedMap = Collections.synchronizedMap(new HashMap());

Adam

 

[Tony Morris]

A hashmap is not synchronized and faster than hashtable.

In a servlet application when you have httpsession to take care of
session independance, is there any reason that I should use hashtable
over hashmap?

Thanks.

Whether or not you provide thread safety to the data held by the structure
is entirely up to how you access (read/write) it.

If you need thread safety, the "Collections way" (as opposed to the old
Hashtable way) of doing that is:
Map m = new Collections.synchronizeMap(new HashMap());

--
Tony Morris
(BInfTech, Cert 3 I.T., SCJP[1.4], SCJD)
Software Engineer
IBM Australia - Tivoli Security Software
Home : +61 7 5502 7987
Work : +61 7 5552 4076
Mobile : 0408 711 099
(2003 VTR1000F)

 

[TP]

Well adam,

the application taht i am working with was orignally built with java
1.1 and there are hashtables all over. now i need to at least stop
creating any more hashtables and remove the ones i can with hashmaps.

thanks.

 

[Anton Spaans]

The Hashtable class was created before the current Collection API was
designed. There's really no reason to ever use Hashtable anymore except
for interacting with existing code which uses a Hashtable. If you need
a synchronized version of HashMap, you can get it by calling

Map syncedMap = Collections.synchronizedMap(new HashMap());

Adam

Hi Adam,

Why shouldn't you use Hashtable if you need a synchronized (hash-)map?
The class nor its methods are deprecated. And the
Collections.synchronizedMap(...) creates an extra object (implementing Map)
as a wrapper around the input-map. Why would you want to do that, if you
have a perfectly good Hashtable lying around?

-- Anton Spaans.

 

[David Zimmerman]

I've been hearing everybody championing HashMaps over Hashtables
becuause they're unsynchronized, therefor much faster for quite some
time. I tried to benchmark the two and I got results which are puzzling.
The test does not try to measure the performance directly, instead it
compares the two. The test has lots of other stuff going on but that
stuff should be identical for each.


Here's my test code

import java.util.*;

public class t
{
static final int ITER = 500000;

static void doHash (Map t)
{
for (int i=0; i<ITER; ++i)
{
Integer in = new Integer(i);
t.put(in, in);
}
for (int i=0; i<ITER; ++i)
{
Integer in = new Integer(i);
Object o = t.get(in);
if (!(o instanceof Integer)) // Do something with the result
System.out.println(i+" wasn't an Integer");
}
}


public static void main (String[] argv)
{
// Warm up hotspot
for (int i=0; i<3; ++i)
{
doHash(new Hashtable());
doHash(new HashMap());
}

// Time the calls
for (int i=0; i<10; ++i)
{
Map t = new Hashtable();
long start = System.currentTimeMillis();
doHash(t);
System.out.println("Hashtable
"+(System.currentTimeMillis()-start));

t = new HashMap();
start = System.currentTimeMillis();
doHash(t);
System.out.println("HashMap
"+(System.currentTimeMillis()-start));
}
}
}

I ran my test with -server, as it gave better times (as expected)

java -server -cp . t


On Red Hat Fedora, running an PIII, 700MHz 512MByte ram
java version "1.4.2_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)
Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)

Hashtable 2461
HashMap 4104
Hashtable 2502
HashMap 4609
Hashtable 3174
HashMap 4062
Hashtable 2788
HashMap 5572
Hashtable 2516
HashMap 4094
Hashtable 2471
HashMap 4094
Hashtable 2482
HashMap 4026
Hashtable 2444
HashMap 4091
Hashtable 2460
HashMap 4063
Hashtable 2480
HashMap 4081




On Mac OSX 10.3, on a G3 450MHz 768MByte ram
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-99)
Java HotSpot(TM) Client VM (build 1.4.1_01-27, mixed mode)

Hashtable 4361
HashMap 5705
Hashtable 4366
HashMap 5640
Hashtable 4188
HashMap 5807
Hashtable 4313
HashMap 5793
Hashtable 4054
HashMap 5648
Hashtable 4197
HashMap 5749
Hashtable 4428
HashMap 5692
Hashtable 4110
HashMap 5955
Hashtable 4282
HashMap 5552
Hashtable 4216
HashMap 5776



On W2K on 1 PIII 1000MHz, 1GByte ram
java version "1.4.2_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_01-b06)
Java HotSpot(TM) Client VM (build 1.4.2_01-b06, mixed mode)

Hashtable 1502
HashMap 2945
Hashtable 1462
HashMap 2954
Hashtable 1492
HashMap 2855
Hashtable 1392
HashMap 2954
Hashtable 1462
HashMap 2944
Hashtable 1452
HashMap 2934
Hashtable 1472
HashMap 2954
Hashtable 1503
HashMap 3134
Hashtable 1422
HashMap 3005
Hashtable 1432
HashMap 2994


It looks like the Hashtable is considerably faster than the Hashmap

 

[Dale King]

Why shouldn't you use Hashtable if you need a synchronized (hash-)map?
The class nor its methods are deprecated. And the
Collections.synchronizedMap(...) creates an extra object (implementing Map)
as a wrapper around the input-map. Why would you want to do that, if you
have a perfectly good Hashtable lying around?

One other minor advantage of HashMap over Hashtable is that it allows null
both as a key and a value. Hashtable does not.

Another is that Hashtable violates naming conventions ;-). Seriously I had
to go back and correct my accidental typing of HashTable.

I agree that there is no great motivation in changing existing code except
that if you don't need it to be synchronized it can be faster (although
synchronization in the absence of contention is almost zero time anymore).
New code should not use Hashtable unless it needs to be usable in JDK1.1.

 

[javabudy]

1. The HashMap class is roughly equivalent to Hashtable, except that it is unsynchronized and permits nulls. (HashMap allows null values as key and value whereas Hashtable doesn't allow nulls).
2. HashMap does not guarantee that the order of the map will remain constant over time.
3. HashMap is non synchronized whereas Hashtable is synchronized.
4. Iterator in the HashMap is fail-safe while the enumerator for the Hashtable isn't