In message <[EMAIL PROTECTED]>, Dan OConnor
<[EMAIL PROTECTED]> writes
>On 16 Aug 00, at 0:48, Juha Lindfors wrote:
>
>>
>> Hi,
>>
>> At 16:55 15.8.2000 -0400, you wrote:
>> >Object's default implementations of hashCode and equals compare
>> >the object instance (i.e. the "memory location") without regard to
>> >semantics (i.e. the meaning of the object). In other words,
>> >person1pk will not always equal person1pk, if these are different
>> >instances of the same key.
>>
>> What I was trying to get at was that I don't see a way the container can
>> determine that the semantics of the said two methods are meaningful in
>> order to refuse deployment. We can determine that the contract is correct,
>> that equals() is reflexive, symmetric and transitive and within a
>> reasonable doubt even consistent. But the Object's default implementation
>> fulfills this contract as well -- and it's not considered "suitable".
>>
>> So my question still remains, how do we define a suitable implementation
>> for these methods in order to reject the non-suitable ones?
>
>Ah. Now I get it.
>
>I suggest that we deploy any entity whose primary key overrides
>both methods (assuming it passes all other tests), and refuse to
>deploy any entity whose primary key fails to override either.
>
>I believe that providing a more complete "suitability" test would be
>difficult beyond any value that it had.
>
>-Dan
I agree with Dan. The critical thing is that a PK has *value* semantics,
whereas the equality test and hashcode provided in Object have
*reference* semantics. We (jboss) could make a reasonable stab at
providing value-oriented hashing, but the spec tells us that it is not
our responsibility to do that.
Justin
--
Justin Forder
