[concurrency-interest] Re: AtomicInteger and AtomicLong should implement Number
7 Jan 2004 18:13:58 -0000
> > (Also note that AtomicReference is not a java.lang.ref.Reference.)
> It might be helpful to note that AtomicReference<T> doesn't extend T. T
> isn't a supertype of AtomicReference<T> because Ts are values and
> AtomicReference<T>s are references to values, and values and references
> to values have fundamentally different characteristics. And since
> AtomicReference<T> doesn't extend T there's no reason to expect it to
> extend any supertype of T other than Object either.
> The analogy then is that AtomicInteger is roughly logically equivalent
> to AtomicReference<Integer> hence it's not an Integer, in which case
> there's no reason to suppose it's a Number either.
My understanding is that Integer and AtomicInteger are both thought to
contain a primitive (JLS 4.2) value, not a reference (JLS 4.3) value,
and AtomicReference contains a reference value, not a primitive value.
If indeed an AtomicInteger contained a reference to an object, and the
get() method returned that object reference, and there were no methods
(addAndGet(), getAndIncrement() et al) short-circuiting to numeric
primitive values (JLS 4.2.1 and 4.2.3), then I think it would make sense
to say that AtomicInteger is equivalent to an AtomicReference<T> where
T is Integer. But AtomicInteger, AtomicLong, etc, DO contain methods
peculiar to numeric primitives, so clearly those classes are NOT simply
an AtomicReference for a reference value which happens to be to an
Integer object, Long object, etc.
IF AtomicInteger only had the methods of AtomicReference, with the
type "V" replace by "Integer", then I think there would be much less
confusion than with the proposed hybridized classes which sort of look
like like AtomicReference, and sort of look like an object-oriented
version of a numeric type for a language which does not have operator
overloading. Conversely, if an attempt was made to meaningfully add
methods addAndGet(), getAndIncrement() et al from AtomicInteger to
AtomicReference, with "int" replaced by "V", then I think it might
become more clear that there is something fundamentally different
about an AtomicInteger from an AtomicReference, and that difference
is what may make some people be inclined to say it looks to them like
AtomicInteger has had features added to it which make it perform like
an object-oriented version of a numeric value, which up until now was a
role assigned to the "Number" class, and that might lead to a feeling
that "AtomicInteger and AtomicLong should implement Number".