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

Doug Lea dl@cs.oswego.edu
Tue, 6 Jan 2004 19:55:26 -0500

The package documentation for atomics has the main rationale
for not relating AtomicInteger etc to Number:

     ... And atomic classes are not general purpose replacements for
     java.lang.Integer and related classes. They do NOT define methods
     such as hashCode and compareTo. (Because atomic variables are
     expected to be mutated, they are poor choices for hash table
     keys.) Additionally, classes are provided only for those types
     that are commonly useful as atomics. For example, there is no
     atomic class for representing byte. In those infrequent cases
     where you would like to do so, you can use an AtomicInteger to
     hold byte values, and cast appropriately. Similarly, you can hold
     floating point types using Float.floatToIntBits and
     Float.intBitstoFloat conversions.

Note in particular that AtomicInteger cannot be a Number because it
would break the hashcode contract. And it would not have a symmetric
equals method.  

(Also note that AtomicReference is not a java.lang.ref.Reference.)

My first version of AtomicInteger actually was called AtomicInt, which
at the time sounded like a good indicator of difference.  But this ran
against the strange but consistent convention of spelling out Integer
when it appears in Java class names. And no such naming trick is
available to indicate that AtomicLong is not related to Long.

Things might have been different had there been pre-existing classes
MutableInteger, MutableLong, etc, but there aren't.

So my current view is still that the names of these classes are about
the best we can do.