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

Dawid Kurzyniec dawidk@mathcs.emory.edu
Wed, 7 Jan 2004 00:00:57 -0500


> (...)
> Note in particular that AtomicInteger cannot be a Number 
> because it would break the hashcode contract. And it would 
> not have a symmetric equals method.  

I completely agree with EG in this case. The only gain of using AtomicX
classes as Numbers is a syntactic sugar, anyway. Baited by that sugar,
people would start abusing them by using them as mutable primitive
wrappers in non-concurrent settings. This is clearly not the purpose of
those classes (if only because of their package location), and it should
not be encouraged. In concurrent end-user applications, the object model
is usually much coarser than single numeric values; it tends to have
specialized classes (possibly having atomic fields) and those classes
may implement any contract you like; e.g. there may be accessor methods
which return values of atomic fields as Numbers if you like. Given that,
and the fact that the syntactic sugar will actually be provided in 1.5
by autoboxing, the discussion almost comes down to whether .get() should
be explicit in the code or not. In his last posting, Doug Lea provided
quite strong semantical arguments to support the EG position on that,
which in my humble opinion should conclude this thread.

Regards to all,
Dawid Kurzyniec