[concurrency-interest] Re: AtomicInteger and AtomicLong should implement Number (Miles Sabin)

David J. Biesack David.Biesack@sas.com
Wed, 7 Jan 2004 13:05:27 -0500 (EST)


> From: Miles Sabin <miles@milessabin.com>
> To: concurrency-interest@altair.cs.oswego.edu
> Subject: Re: [concurrency-interest] Re: AtomicInteger and AtomicLong should implement Number
> Date: Wed, 7 Jan 2004 08:31:23 +0000
> 
> 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.

Actually, AtomicInteger is more analogous to AtomicReference<int>
not AtomicReference<Integer>. But int is not a reference type.

As per the package doc

  "Atomics are not used very often in application-level classes. They
  are designed primarily as building blocks for implementing
  non-blocking data structures and related infrastructure classes."

Thus, these classes are not used in contexts where Number and its
subclasses are useful; i.e. not as wrappers for primitives to store
in collections, etc.

That's why there is no AtomicFloat/AtomicDouble. To further the
distinction, the value method is 'int get()', not 'int intValue()', and
AtomicInteger does not implement Comparable. This all feels right to me.

One option (which I offer but do not support) is to rename this as
AtomicInt (*not* AtomicIntegerReference!) to emphasize the int value.
The "problem" still exists for AtomicLong/AtomicBoolean. The other
reason I don't support this option is that I think the name
'AtomicInteger' reflects the fact that it holds an "integer" value,
thereby hiding to the implementation detail that it uses an int. (Too
bad the javadoc is more explicit: "... maintains an <tt>int</tt> value...")
Maybe AtomicLong should really be AtomicLongInteger :-)

I agree it is sufficient to let the Javadoc clarify the intent and use.
It may be worth adding a brief paragraph to the package doc.

> Miles

-- 
David J. Biesack     SAS Institute Inc.
R&D Java Strategist  SAS Campus Drive Cary, NC 27513
(919) 531-7771       http://www.sas.com