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

Larry Riedel larryr@saturn.sdsu.edu
6 Jan 2004 04:13:35 -0000

> The AtomicX classes are "wrappers" for accessing primitive values or
> references using atomic instructions. AtomicInteger is not a wrapper
> for java.lang.Integer and the name was not meant to imply that. The
> atomic classes allow for lock-free synchronization in some situations
> (though actual lock-freedom is a quality of implementation issue).

My impression, as someone who would just be an application
programmer using stuff in java.util.concurrent, is that
AtomicInteger is in essence providing "atomic test and set" of a
numeric value, a most fundamental operation.  If so, then I think in
the context of an "object-oriented" style API it might be natural
to hope an AtomicInteger would provide a way to /be/ the value it
contains, in the same way an Integer does.  It is because of this
impression I have that I think it makes sense to wonder "why is an
AtomicInteger not a Number" (the topic of this thread).  Just from
looking at the JDK, I think one good answer could be "because legacy
issues with Number make it undesirable from an implementation point
of view"; but it would still make sense to me to try to provide
/some/ shared ancestor type which provides a /single/ way to get
the value from an Integer /or/ an AtomicInteger.  However, if there
is an expectation that the AtomicInteger will not be the means for
seeing the value, then I guess whatever else is taking care of that
should worry about how to "be" the value.  Also, I have no idea how
this all fits in with "autoboxing"-- maybe it is all moot because
there will just be an "operator int()" or something like that?