Hashtable vs. HashMap

I have had a Hashtable in one of my programs now for a few years. I am using the latest version of NetBeans with its new warning and hint system. I recently made some changes to one of my programs and got the warning that HashMap should be used in the place of Hashtable. As I have not been following changes in the core Java classes, I was not aware of this. Would it be better to leave the Hashtable alone or upgrade it to HashMap? I have read that HashMap is a bit slower than Hashtable, or WAS slower.

Thanks.

Actually it depends on your scenario

Could you elaborate on what you mean by scenario?

I have about 1,450 JavaBeans with associated keys in memory after program startup like so Hashtable<String, FilmBean>titles; if that is what you mean bu scenario.

The main difference between Hashtable and HashMap is that Hashtable is thread-safe and HashMap is not. You should look at the java.util.concurrent package for a better alternative for Hashtable.

Thanks Wouter. I was more worried from the standpoint of lagacy, I mean if ever Oracle decided to discontinue completely Hashtable. I am only a hobby programmer, so not immersed in it day and night. The Hashtable is incredibly fast in the JTable so I don't see why I should change it other than disconuiation of Hashtable and there are not changes performed in Iteration.

My first thought would be

if it an't broke, don't fix it

The classes in the java.util.concurrent package should be even faster. Java has never removed something so don't worry about that.

Isaac Hewitt wrote:I have read that HashMap is a bit slower than Hashtable, or WAS slower.

Do you have a source on that? Because I find that statement highly questionable. If either class would be slower in the past, I would have said Hashtable because of its (often unnecessary) synchronization.

Wouter Oet wrote:The main difference between Hashtable and HashMap is that Hashtable is thread-safe and HashMap is not. You should look at the java.util.concurrent package for a better alternative for Hashtable.

Nitpick: conditionally thread-safe (as is the Collection.synchronizedMap() wrapper).
While individual operations are thread-safe, a sequence of operations might not be.
For instance a put-if-absent operation, implemented as an invocation containsKey() followed by an invocation of put(), would require additional synchronization to make it atomic, thus preventing a race condition. The same goes for iteration using, for example, entrySet()'s fail-fast iterator. Additional synchronization would be needed to prevent another thread from structurally modifying the instance to prevent a ConcurrentModificationException.

thank you for all of your responses. please keep in my that i am a hobby programmer albeit fairly good and what i really want to know is if hashtable will be discontinued, and so sould change it to hashmap

Isaac Hewitt wrote:As I have not been following changes in the core Java classes, I was not aware of this.

You didn't notice that in the release notes for Java 2 when it came out in 1998?

Just make the change to HashMap. Hashtable is not likely to go away but really, after 12 years of being the preferred alternative, HashMap should get a little consideration.

Jelle Klap wrote:

Wouter Oet wrote:The main difference between Hashtable and HashMap is that Hashtable is thread-safe and HashMap is not. You should look at the java.util.concurrent package for a better alternative for Hashtable.

Nitpick: conditionally thread-safe (as is the Collection.synchronizedMap() wrapper).
While individual operations are thread-safe, a sequence of operations might not be.
For instance a put-if-absent operation, implemented as an invocation containsKey() followed by an invocation of put(), would require additional synchronization to make it atomic, thus preventing a race condition. The same goes for iteration using, for example, entrySet()'s fail-fast iterator. Additional synchronization would be needed to prevent another thread from structurally modifying the instance to prevent a ConcurrentModificationException.

True but Java only allows for a method scope synchronization block. You can combine multiple methods into one to overcome this limitation (like the java.utilities.concurrent classes do). You could also use locks to synchronize because they allow for a wider scope and allow the release of locks in an order different then the order of obtaining them.