[concurrency-interest] Re: AtomicInteger and AtomicLong should implement Number
Wed, 14 Jan 2004 10:30:13 -0600
I don't know how germane it is, but I'm skeptical that
most stateful classes in Java provide identity-based equality
semantics. The Collections Framework springs immediately to
mind. This is just a gut feeling, I don't have any hard numbers.
Of course "most" is a pretty nebulous concept in this case.
Collections are heavily used. Do they therefore count more
than other classes? Do the objects used in collections count
for more than the collections themselves?
When the natural equality test is state-based,
there isn't much reason not to implement it, despite any
problems it causes when used as a map key.
1. If you somehow know there will be no state changes,
it is a safe map key
2. If you think there might be a problem with mutability,
you should have an immutable variant, too
3. IdentityHashMap means it can still be a map key even
in the face of state change
4. All the identity based information is still easily
accessible via == and System.identityHashCode()
5. Since both equality types are readily available,
there is less reason to hesitate making the class final.
I'm a believer in declaring classes final, unless they were
designed with extension in mind.
In short, defining state-based equality in the class usually
makes it easier for the user to pick the desired equality type.
[mailto:firstname.lastname@example.org]On Behalf Of Doug Lea
Sent: Wednesday, January 14, 2004 9:19 AM
Cc: Dawid Kurzyniec; email@example.com
Subject: Re: [concurrency-interest] Re: AtomicInteger and AtomicLong
should implement Number
To try to recap decisions:
1. AtomicInteger extends Number to allow uniform access
to values by tools and utilities. (Similarly for toString
2. It provides identity-based semantics for equality, as do
most stateful classes in Java.
3. In those cases where people want value-based equality etc
they can either rely on autoboxing, which provides reliable
semantics at the possible cost of overhead, or create subclasses
that add on particular equals, hashCode, and/or compareTo methods.
I believe that everyone has some straightforward path to getting desired
effects, and no reasonable usage is ruled out.
Concurrency-interest mailing list