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

Boehm, Hans hans_boehm@hp.com
Thu, 8 Jan 2004 14:50:36 -0800

[I think my last attempt to post this is still awaiting moderation
due to a slightly different sender address.
This was in reply to Doug's message about the hashcode contract.]

I think we're still interpreting Number in different ways.  I see
nothing in the spec that requires equals() on subclasses of Number
to reflect numeric equality.  I agree that for AtomicInteger that
wouldn't be desirable.

I reread the number spec and it still seems to imply nothing but
convertibility to numeric types, in spite of its name.  If there is
agreement that it was intended to imply more than that, it would
be good to know what it is, and I wish it were stated somewhere.

If someone can point to a stated property that is violated by having
AtomicInteger inherit from Number, implement the Number methods, but
leave the default implementations of equals() and hashCode() in place, I'd
be happy to change my mind.

It seems to me that both interpretations of the Number class (is an
immutable number vs. can be converted to numeric types) make sense and
are useful.  (Perhaps both should be interfaces, but I don't see
why that's relevant to this discussion.)