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

Gregg Wonderly gregg.wonderly@pobox.com
Tue, 06 Jan 2004 21:38:03 -0600

Doug Lea wrote:

> 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.

I have heard a lot of explanations about why you all didn't expect that 
these types would be construed as 'Number' values.  But I guess I still 
do not see why that can not be Number implementations.  Your planned use 
of these values is fine with me.  But, I really think there is a large 
value in the presence of these classes and I really think they should be 
Number values.  I also think that there should be an AtomicDouble as 
well.  I understand that these are new/different uses than what was planned.

What I want to encourage is that these other uses are just as valid and 
I think that if this gap isn't closed, that we'll end up with a new set 
of such classes somewhere else that will more completely fill this void 
and then we'll have the disparity that I'd like to avoid.