Re: Handling the throwable "ThreadDeath"
markspace wrote:
Eric Sosman wrote:
Neither HashTable nor StringBuffer is deprecated. In fact, no
method of either class is deprecated.
Really? I thought they were. Hmm, ok I may have to retract my statement.
Certainly the places where those classes where sometimes used seemed
dubious, however. E.g., a StringBuffer used where clearly
synchronization could never be useful.
In code written before StringBuilder came along, I'd imagine. It
would (presumably) be possible to put a gang of interns on the task of
turning StringBuffers to StringBuilders throughout a large existing body
of code. But absent another reason to visit a source file, is it worth
the trouble and risk? (If you think the risk of breakage is zero in
such an exercise, you've not been around software long enough ...)
The cost of acquiring and releasing a StringBuffer's lock in the
absence of contention is pretty small. A quick measurement on my
desktop machine indicates 55.2 ns to append a three-character string to
a StringBuffer and then delete the three characters, 40.5 ns to do the
same to a StringBuilder, so the synchronization penalty is something
like 7.4 ns per operation. If my program does a hundred million
StringBuffer operations, switching to StringBuilder would save me not
quite three-quarters of a second. Hoo-ray. (YMMV, obviously.)
If it were my body of code to maintain (it isn't), I would not
hire that gang of interns. Rather, I'd suggest that whenever a module
is modified for some other reason, it might be a good idea to change to
StringBuilder at the same time, allowing the tiny speedup to [obligatory
Java pun] percolate gently through source tree. And I'm not at all sure
I'd encourage wholesale changing of HashTable to HashMap -- they are not
perfect work-alikes and have different performance characteristics, so
the risk of messing something up would be noticeably higher.
--
Eric.Sosman@sun.com