[concurrency-interest] Re: AtomicInteger and AtomicLong should implement Number
Fri, 9 Jan 2004 12:33:16 -0500
> Of course the same arguments can be made for AtomicIntegerS
> being Comparable. Why aren't AtomicIntegerS comparable?
Because you cannot rely on the result of the comparison anyway, since
the values may be immediately changed by other threads after you compare
but before you use the comparison result. To avoid this, you would have
to use locking, and those classes exist precisely to avoid locking.
In particular, comparable suggests that you can sort objects of this
type, and the sort operation assumes that these objects are constant (at
least for some time), which is clearly the opposite of why those classes
are to be used. Again, you would have to lock to make sure that the
values do not change at least _during_ sorting.
> In short, extending Number doesn't make AtomicInteger error-prone.
Sorting or comparing mutable values is extremely error prone.
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.