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

Curt Cox ccox@tripos.com
Fri, 9 Jan 2004 14:16:28 -0600


"Also, to argue on the "philosophical" level why numbers in Java are
immutable: 2 is a number, and 3 is a number, but something which can be
sometimes 2 and sometimes 3 is not a number, it is a variable (or number
holder which you can query for its momentary value). Java builds upon
that definition: everything that extends the Number is immutable. This,
for instance, allows to sort arrays of numbers regardless of the actual
type. Proposed change would violate this."

This argument is compelling.  If it is the rationale for not using
number as a base class, then Number should document that restriction.
If there really is a consensus among Java programmers that Number
implies immutability, then there should be little argument about
adding this advice (there is no possible enforcement) to the Javadoc
for Number.  Of course AtomicX should contain reciprocal documentation
since it won't be readily apparent (consider this discussion as proof)
why an AtomicX isn't a Number.

Likewise for Comparable.  If AtomicX aren't Comparable because they are
mutable, then Comparable should at least mention mutability.  There
should be reciprocal documentation in AtomicX explaining why they are
not Comparable.

Failure to do all of this will result in several bugs being filed on
Bug Parade (no, not by me) about how AtomicX should be Comparable and
Numbers.  This will be compounded by duplicate filings and countless
programmer hours spent searching the bug database prior to filing
bugs.

It would violate the principle:

"It is OK if they are not happy, we just don't want them confused."