[concurrency-interest] Re: AtomicInteger and AtomicLong should
Tue, 13 Jan 2004 19:03:50 -0600
David Holmes wrote:
> Just 2c on one aspect of this:
>>Gregg Wonderly wrote:
>>Performance is not the primary issue here. The primary
>>issue for me is
>>that I am going to have to synchronize through memory allocation to
>>create all these new objects. I am also going to expand the JVM's
>>memory use to have to representations of the same thing.
>>There seems little advantage to this.
> Isn't this argument a bit overstated given that you must change your
> applications to use AtomicInteger anyway?
What I am refering to is copies of AtomicX values just so that I have a
Number implementation that has compareTo() and equals() as value based.
> If you currently use "int" values as your mutable entities you would
> have to wrap these as Integer at some stage. Now you would use
> AtomicInteger and still have to wrap at the same stage.
I already have a Number implementation in AtomicX. Now I am going to
have to copy that Object to have an Object that has value based
> If you currently use Integer objects and perform calculations then you
> must be creating new Integer objects for results. Replacing Integer
> with AtomicInteger can remove the need for intermediate Integer
> objects, but you still need the final Integer to hold the result from
I don't need a value from get() with these objects extending Number if
they are also Comparable and have value based equals()
> Anyway this point is moot now that AtomicInteger will extend Number.
No, I talking about the specific instance of private code that uses
Number based values that now must be changed to be different about the
use of Object.equals because these Number implementations don't have a
value based .equals().