(sorry for the double list post if two mails went in, I received a
mailer daemon error on two posts attemps)
Thanks Gary for your explanation, I also had a look at Long javadoc
and seeing its overriden equals(), I understand my false boolean when
doing "==".
However, as Jörg said, I don't understand why EqualsBuilder isEquals
seem to use object identity "==" and not identitity.
I thought it may be related to the appendSuper(super.equals(object)),
but my bean does not extend some weird class, however, it implements
Serializable, with an eclipse-generated serialVersionUID of
4428981846813391173L.
Would it relate to my hashcode() instead ? Mine uses the Long id
property too, and is :
public int hashCode() {
return new HashCodeBuilder(1054718011, -1215537567).appendSuper(
super.hashCode()).append(this.id).toHashCode();
}
laurent
2007/12/17, Jörg Schaible <[EMAIL PROTECTED]>:
> Gary Gregory wrote:
> > Hello Laurent:
> >
> > This behavior is 'normal'. The concepts of object equality
> > (the equals() method) and object identity (==) are different.
>
> Well, this was not Laurent's question. He was wondering, why the
> EqualsBuilder seems to use in his example the Long objects' identity instead
> of their equals method.
>
> [snip]
>
> - Jörg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
<a href="http://in-pocket.blogspot.com";>http://in-pocket.blogspot.com
- Mobile world, technology and more</a>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
