[ Tim Peierls ] [concurrency-interest] Re: AtomicInteger and AtomicLong should implement Number
Wed, 14 Jan 2004 22:19:18 -0600
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:concurrency-
> email@example.com] On Behalf Of Gregg G. Wonderly
> The arguments against are emotional. ...
They shouldn't be.
> ...I threw in the "myopic view" comment because
> I don't know how else to classify Dawid's arguments that focus solely
> the "AtomicX can never be used as a Map key" issue.
I personally think his argument is that they have a specific purpose,
and that purpose is not to be used anywhere currently Number objects are
I could also use StringBuffers as map keys or numbers, but that doesn't
mean I should.
> a new issue at all. People have already learned, or will learn after
> make the mistake that they can't use changing hashCode() classes in a
> as keys. This lesson has already been learned by many, including
> So, rather than restrict the use of these classes because one use case
> problematic. I think we should make the functionality of these
> line with the existing Number instances that are native type
> that everyone can use these numeric values as numeric values and not
> to wrap them in some other container to get a value based equals() and
I still am not really convinced that they are "numeric" values in the
sense that Integers or other Numbers are. To me, they are a container
holding an int or long, which has atomic change properties and from
which I can obtain a snapshot of the contained value via the get method.
However, having said that, I could potentially see where a mutable
Number object has value, perhaps in embedded systems, where memory and
performance have much tighter constraints. In those situations, I could
see where these features could potentially be helpful.
So, perhaps they should have full numeric capabilities, along with a
stern warning in the javadoc that this is provided only for special
circumstances and should not be used for hash keys or sorting due to the
mutability of the underlying value. (Too bad there's only the deprecated
tag to cause warnings...)
Or, a second set of AtomicComparablexxxx classes could be created,
complete with the notation that these are extremely special purpose
classes, to be used very carefully....