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

Gregg Wonderly gregg.wonderly@pobox.com
Mon, 12 Jan 2004 22:10:06 -0600

Doug Lea wrote:

>>and take the risk that if 
>>there is an object in a hashtable and its value changes, it may
>>may not be findable using the same key value as before.
> Under the current scheme, anyone who want to use an AtomicInteger
> with value-based semantics as a key in a hash table, only has
> to say "get()"
>   table.put(myAtomicInteger.get(), something); // value-based

In applications where I am already doing this with other Number 
implementations, the native value is already in the box.  So, what your 
saying is that it makes more since to do

	table.put(NumberRef.intValue(), something)

and let autoboxing create a completely new object that is separate from 
and apart from the value I already have?

I think that is shortsighted.  I really do understand what you're trying 
to prevent from happening.  I just don't think that the safeguards that 
you are trying to put in place have any real value proposition to the 
use of these classes compared to the value that having the value based 
equals and compareTo would.