[concurrency-interest] Re: AtomicInteger and AtomicLong should implement Number

Doug Lea dl@cs.oswego.edu
Mon, 12 Jan 2004 06:19:36 -0500

> But it looks to me like things are not going that way, for example it
> appears AtomicInteger will provide intValue(), but will not provide
> the corresponding obvious(*) implementations of compareTo(), equals(),
> and hashCode(), because "usages would almost never be correct".  MY
> assumption would be that with competent software engineers at the helm,
> which I think should be a fundamental assumption behind ALL API design,
> usages would be as correct as they are with anything else.

The rationale isn't based on competence.  While I can't think offhand
of any application where I'd use AtomicIntegers as keys in a hash
table (HashMap, Hashtable, ConcurrentHashMap), if I did, I would
surely want to be able to find them even if they changed value. Using
the default identity-based hashCode and equals methods provides this;
so normal usages would almost always be correct, while with
value-based versions, they almost never would be. And given this,
because you aren't supposed to define a compareTo that returns 0
(equals) in different cases than when equals returns true, the only
option is not to provide it.