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

Larry Riedel larryr@saturn.sdsu.edu
15 Jan 2004 06:54:57 -0000

> [AtomicX] have a specific purpose, and that purpose is not to be
> used anywhere currently Number objects are used. 
> I could also use StringBuffers as map keys or numbers, but that
> doesn't mean I should.
> [...]
> 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.

I think it would have been fine and natural to have an
"AtomicPrimitiveVariable" and an "AtomicReferenceVariable",
corresponding to the two kinds of types in the Java language,
and to the wording ("atomic variables") of the JSR.

Having "LongAtomicPrimitiveVariable" and "IntAtomicPrimitiveVariable"
sounds pretty good to me too-- whatever most clearly distinguishes
the "container" from the "contained value".  The documentation could
hopefully provide some explanation for why what looks like it should
have been a feature of the compiler ("atomic int") has become a
class/entity inside the JVM ("IntAtomicPrimitiveVariable"), which would
make it clear that the way things are done is not because any sane
person would have wanted to do it that way, but because the alternative
was to continue with no atomicity facility at all, and so like with
most of the nice new things coming from JSRs, half of it is some sort
of workaround for the legacy of crud they had to preserve.