[concurrency-interest] Re: AtomicInteger and AtomicLong should
Fri, 9 Jan 2004 10:35:28 -0800
You cannot sort, and neither can you take the hashcode based on content,
nor you can use the content for Maps (you can use the object identity for
that, but that's not Number).
Traditionally Number classes have been always considered wrapper of
primitive values, and although not documented black on white in the
contract, the habits of Java programmers are also important, as per the
principle of least surprise. We wouldn't want some new linux distribution
to put configuration files in /tmp.
And I don't know why this discussion is important, because I haven't seen
in ages (or maybe I haven't seen at all), an interface using Number for
parameters. And if I see one, when I pass a Number in there, I might be
suspicious that it may legitimately be used for hashing or comparison, or
all other long term, so I'd avoid as a matter of principle to pass in a
mutable value, even a mutable value that is typically modified from other
threads, therefore even if the module that I'm using is not using it beyond
the scope of the current call, it should be safe.
That there might be some usages where passing an AtomicXXX, rather than
AtomicXXX.xxxValue() may be provably safe, I have no doubt, but I really
wonder whether it really makes such a big performance difference. As Java
has always erred on the side of caution, as opposed to performance, I'd
rather not want that some programmer be so concerned with performance that
he will want to pass an AtomicXXX directly where a Number is expected.
Just my 2c,
<firstname.lastname@example.org> To: <email@example.com>
Sent by: cc:
concurrency-interest-admin@cs Subject: RE: [concurrency-interest] Re: AtomicInteger and
.oswego.edu AtomicLong should implement Number
01/09/2004 09:33 AM
> 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.
Concurrency-interest mailing list