[concurrency-interest] Re: AtomicInteger and AtomicLong should implement Number
Wed, 7 Jan 2004 18:18:41 -0500
>> 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.
> where you would like to do so, you can use an AtomicInteger to
> hold byte values, and cast appropriately. Similarly, you can hold
> floating point types using Float.floatToIntBits and
> Float.intBitstoFloat conversions.
I agree with Gregg, this AtomicDouble should exist, even if this implies to use a lock as mentionned later by David. This way the 'family' will be complete. Even if the AtomicXXX were intended for a different use, this will avoid developers the creation of AtomicFloat/Double classes which could be broken. It's conceivable that someone will have to upgrade the AtomicInteger/Long to some floating type. We also do not want to play with Integer/Float bit conversion. If the class is using a lock and has other differences related to performance and others, mention it in the javadoc.
For the Number aspect, it is just too bad that Number is not an interface instead of a class. My opinion is that it's safer to not extend Number and to create your own wrapper around AtomicXXX if you really need to have a Number compatible class with an atomic access.
For hashCode() and compareTo(), we don't define them and it's perfectly in line with the contract as defined in Object.
<<However>>, I would expect toString() of the AtomicXXX classes to return a String in the same format as the XXX.toString() for its current content. Currently it must be some kind of garbage with the address.
Your opinion ?