On 15 Aug 00, at 23:29, Juha Lindfors wrote:
>
> Hi,
>
> At 20:24 14.8.2000 -0400, dan o'connor wrote:
> >On 14 Aug 00, at 17:14, marc fleury wrote:
> >> In the case that the developer supplies a ComplexPK (aggregate of fields),
> >> currently, we have no other choice but to rely on the hashCode and equals
> >> that it supplies to do our internal EJB cuisine.
> >>
> >> does the spec say that you should overwrite hashCode and equals??? I don't
> >> think so...
> >
> >Hi Marc,
> >
> >Yes it does, in 9.2.9. We should refuse to deploy an entity with a
> >PK that does not override hashCode and equals.
>
>
> How do you define a "suitable" implementation of a hashCode() and equals()
> methods?
Hi Juha,
A suitable implementation of equals will allow us to correctly
differentiate between entities of the same component type using
only the primary key. In other words, if PersonPK pk1 .equals
PersonPK pk2, then the entities associated with each primary key
refer to the same data, and if they are not equal they refer to
different data.
A suitable implementation of hashCode must be consistent with
equals, i.e. if pk1 .equals pk2, then pk1.hashCode must equal
pk2.hashCode. (Note that the opposite is not true.)
Ideally, the hashCode implementation will provide a good spread of
values based on the expected data. In other words, person1
person2 and person3 will usually have different hash code values.
This is not an absolute requirement, unless you want hash lookups
to be faster than a simple search through a list. :-)
> If I have a generic ComplexPK as a superclass that overrides
> these two methods, is it suitable enough?
It is suitable enough if it meets the criteria above.
Or would I have to override these
> methods for all subclasses of generic complexPK class as well? If not, why
> isn't the Object class's implementation of hashCode() and equals()
> considered suitable?
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.
> If yes, why doesn't the spec clearly state that all
> complex pk's MUST override these two methods?
Well, it is stated in 9.2.9, but it could be clearer.
>
> -- Juha
>
>
>
>
>
>
>
