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

Larry Riedel larryr@saturn.sdsu.edu
14 Jan 2004 21:42:02 -0000

> I'm skeptical that most stateful classes in Java provide
> identity-based equality semantics. [...]
> When the natural equality test is state-based, [...]

To me it seems intuitively pretty clear that introducing a facility
which adds atomic access semantics to an entity does not justify
changing the way that entity is compared with other entities of that
type.  So I think if the manifestation of the facility is to have a
class whose instances are surrogates for the entities, the surrogates
should, to the extent feasible, try to assume the type and comparison
semantics of those entities.  I think it is fair to assume that entities
which are fundamentally used as numeric values will have numeric
comparison semantics.

Also, I think if the phrase "at the same apparent relative location
inside the JVM" was used instead of "identity-based equality" to
describe the use of the "==" operator on a pair of Java reference values
(JLS 4.3), it might do a better job of making it clear that using Java
"==" as an equivalence operator for identity may have little or no
intuitive high level meaning.

It makes sense to me that relative location inside the JVM would be
important in the context of implementing atomic facilities in the JVM.
And for gut level implementation details of a particular method of a
particular class, I believe it is often expedient to decide to map
"==" onto a locally degenerate interpretation of equal identity.  But I
certainly wouldnt want to have to design my application around the idea
that "==" in Java is synonymous with "identity-based equality".

In situations where I want to partition/distinguish or order
entities/objects based on identity rather than state, I would not
want to be pressured towards using Java reference values to define
identity, or for the JDK to assume they are synonymous.  In the case
of the "Object" class, the root of the type hierarchy, I can imagine
that faced with a decision to throw an exception from equals() and
hashCode(), or try to produce some sort of degenerate implementation
to lower the barrier of entry for people to use the language, I might
choose the latter, but I would not see that indulgence as an excuse for
foundational classes that actually do something to balk at choosing a
more intuitively meaningful implementation.