[ David Holmes ] [concurrency-interest] Re: AtomicInteger and AtomicLong should implement Number
Wed, 7 Jan 2004 09:23:56 +1000
Gregg Wonderly wrote:
> One of the potential uses is to write data to a database
> and objects must be converted to java.sql data types to do this.
> Number types are automatically converted already.
> Another use is reflection. Where, a value is converted to
> a string to be written to a properties file or some other textual
> representation. In both of these cases, the lack of 'is a
> Number' increases the complexity of the code involved.
I'm coming from a position where I see the atomic classes as
specialized syntax for atomically accessing primitive fields. The fact
that we end up with objects is an implementation artefact. I fully
realize there are places where primitives must be objectified to be
used, but I didn't consider direct use of the AtomicX objects as
replacements for current use of Integer et al. I've expected people to
just use get() and turn that into an Integer or Long if needed (though
most usage contexts I'm involved in don't need that - I write
"systems" code, though I have used java.sql in a past life).
What I'm realising from this discussion is that people may well see
AtomicInteger and AtomicLong as mutable replacements for Integer and
Long, even in contexts where the atomicity may not be needed. That
wasn't a usage that I had contemplated - and it does concern me a bit.
Arguably Java needs mutable arithmetic objects but that wasn't what we
set out to do with the atomic classes. We're not trying to fix the
numeric type hierarchy here and I for one would rather not do anything
that suggests that we are.
Code that wants to utilise the atomic classes will be rewritten anyway
and if an AtomicInteger has to be converted to an Integer at some
stage then I don't think that is unreasonable, as an int would have to
have been converted to an Integer too.
> So, anyplace that I have numeric values, I have to use these
> classes. So, for me, these are general-purpose arithmetic
> classes because I do have to use them in lots of places.
They are general purpose wrapper classes - they objectify primitive
numeric types. To be general-purpose arithmetic classes I'd expect
them to support arithmetic (think C++, operator overloading etc).
> I also believe that it would be wise to provide a 'double'
> value version of
> these classes and make them even more generic in expected use.
As far as I am aware you cannot provide AtomicFloat/Double without
using locks. So while we could define such classes it would be
misleading, and not commensurate with the goals of JSR-166. I can see,
from your perspective, how having such a class would make the type
hierarchy more complete - but we're not trying to define a numeric
type hierarchy here.