Re: Handling the throwable "ThreadDeath"

From:

Lew <noone@lewscanon.com>

Newsgroups:

comp.lang.java.programmer

Date:

Tue, 25 Aug 2009 18:49:46 -0400

Message-ID:

<h71pqb$nte$1@news.albasani.net>

Lew wrote:

[...]
Kidding aside, 'HashMap' is a close enough workalike to 'Hashtable'
absent multi-threaded concerns, as long as you take the extra step to
convert any associated 'Enumeration' into an 'Iterable' and replace
any lost methods ('contains()', etc.). If the 'Map' is shared, you
would want the 'Collections.synchronizedMap()' of it, or perhaps
'ConcurrentHashMap' (which covers 'Hashtable' functionality, too,
interestingly enough).

Eric Sosman wrote:

Another difference between Hashtable and HashMap is their behavior
with null keys and values: HashMap is happy with them, while Hashtable
throws NullPointerException. It'd be a pretty weird program that
relied on getting NPE from a Hashtable to find out about nulls, but
we know that the set of weird programs is non-empty ...

A more "practical" concern would likely be the different ways the
two implementations treat their chief tunables, load factor and initial
capacity. Somebody who's invested a lot of effort in choosing Just The
Right Size for his Hashtable, striking a delicate balance between lookup
time and iteration time, may be unhappy when HashMap inflates his
carefully-calculated size to the next power of two, potentially almost
doubling it.

You raise interesting points. My attitude was geared toward situations where
you could feasibly declare the variable as 'Map' and change implementation.
You describe situations where a very specific implementation is necessary, and
naturally my ideas wouldn't apply there. I've run into this sort of thing
recently where I needed to use 'ConcurrentHashMap' and the variable needed to
know that it was of that type.

Like so many other things in this business, the answer boils down to, "It
depends."

--
Lew