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

Doug Lea dl@cs.oswego.edu
Thu, 8 Jan 2004 19:25:27 -0500

> I think my last attempt to post this is still awaiting moderation
> due to a slightly different sender address.

(Worse, I think it got flushed by mistake when discarding some of the
spam that comes into this list. Sorry!)

You are right about Number: Unlike all of its subclasses, it doesn't
make any requirements about hashcodes, mutability, equals, etc.  So
AtomicInteger and AtomicLong COULD subclass from Number.  And we in
the EG are still discussing this, although still leaning against
it. But the reasons at this point boil down to taste. We need a
knockdown argument one way or the other about this to make a confident
decision. Anyone got one?

Some excerpts of discussions:

> I don't think a lot of thought went into Number, so we're basically 
> looking for meaning in chicken entrails.  It is currently the case that 
> all J2SE subclasses of Number are immutable, but Number has a (public) 
> default parameterless constructor (almost certainly accidental, and 
> undocumented to boot), so you can make your own mutable subclass if you 
> like.  

> I don't think we'd be sacrificing any great invariant by having 
> AtomicInteger extend Number, but just because you can do a thing doesn't 
> mean you should.  I think the question is, does having AtomicInteger 
> (and pals) extend Number foster a programming style that we like, or one 
> that we dislike?  Does it have any compelling performance advantages?  I 
> think the answers are "one that we dislike" and "no."  

>  Encouraging use of AtomicInteger as a mutable replacement for
> Integer is not a good thing in my view. Further the only way to use
> numbers in a "generic" fashion is to promote everything to double and
> that's not something I'd want to encourage. When/if-ever there is a
> more complete numeric type hierarchy in Java we can slot in the atomic
> classes (though that would also suggest we provide atomic float/double
> classes).

> Either the Number class spec should say that it is the base class
> for immutable numerical values, or we should subclass from it.

> Regardless of whether the Number class javadoc comment can be changed,
> it's a bad idea for any class to extend an abstract class that takes the
> trouble to list its concrete subclasses in its class javadoc comment,
> especially if the extension is fundamentally different from the listed
> concrete subclasses.

> Byte, Double, Float, Integer, Long, and Short don't bother to document
> their immutability at all, so the absence of such documentation on
> Number doesn't imply mutability. (BigDecimal and BigInteger correctly
> say "immutable" right up front, thanks to Josh.)