Hello,

Some background:

I have a class S extends T. We use lazy loading for S. Superclass T overrides the equality and hashCode methods and implements all kinds of other useful but not persistency related behaviour we wish to use. Since there is a known bug in the implementation of the equality and hashCode implementations of class T, we have re-implemented them as follows:

@Override
public boolean equals(Object o) {
return this == o;
}

@Override
public int hashCode() {
return System.identityHashCode(this);
}

(ie: back to the same implementation as the one in Object).

None of this is related to hibernate as such. However, at some point I have a reference to an object s of S which turns out to be a proxy. If I call:

s.equals(s);

I receive "false" as a reply, although s == s returns true. Further investigation leads me to believe that hibernate swaps the callee object s for the real thing, but does not swap the proxy reference in the method parameter. Upon execution of the equality method, the real thing does a reference compare with the proxy, and fails.

From my perspective as a user, this is a bug and the parameter in the method should be swapped as well, but it's possible there is a good reason for this behaviour. In that case, I would very much like to know this reason to deepen my understanding of hibernate.

Thank you for your time,
Yves

hi,
that's tricky; generally I don't think it's a good idea to implement equals and hashcode like that, if you really need to use them please read:
http://community.jboss.org/wiki/EqualsAndHashCode

Also note that Hibernate does never use nor equals nor hashcode, as it is hard to demand people getting that right. If you're having issues with it, it is most likely because you're adding your object to HashMaps or similar collections which use them.

Hey,

The implementation we used for equality is the same as the one in java.lang.Object. So our case should be identical to a case where the class simply does not override hashCode and equality.

We are forced to override those methods to "revert" an error made in the parent-class (which we currently can not change directly)

Yves

Hello All,

After some more investigation from our group, we have a better understanding of why our solution causes problems.

So, the situation was that

hibernateProxyObject.equals(hibernateProxyObject) returns false, even though the equality method is implemented as ==.

Apparantly, upon invocation of a method in a hibernate session, Hibernate checks whether the equals method is overriden: if so, the proxy on which the equality method is invoked is resolved (see JavassistLazyInitializer line 191/BasicLazyInitializer line 95).



Therefore, what is actually invoked is:

hibernateResolvedObject.equals(hibernateProxyObject), evidently returning false. If you just do not override the equals method, the proxy is not swapped out and the referencecomparison passes. So although our equality implementation is identical to the reference compare, we still get different results. We can not work around this except by not using the parentclass which overrides the equality operator in the first place.

I believe, however, that the fact that hibernate swaps out the callee for the real object, and not the same proxy in the method parameter list is a bug. If you have resolved the proxy anyway, you might as well change the proxy instance in the parameter list to the real thing as well. There seems to be no disadvantage to this, and will fix all problems with == in method implementations and proxies. If this is not a good idea, again I would really like to hear why: I'm always willing to learn :)

Thanks,
Yves