Jeanne Boyarsky wrote:This is how it should work. The id is used in determining the hash code. If you change the id, the hash code changes. This makes sense. If you change an id, the objects are no longer equals. If you change your primary key, what would the meaning of equality be?
Jeanne Boyarsky wrote:Sorry about that. Srikanth said he changed the id and had the same problem so I didn't read your post carefully.
On to your question: Have you confirmed the ops list is not empty? I ask because if the list is empty, it isn't going through the loop at all and the equality method isn't being run either.
H Blogg wrote:Yes. If you look carefully, I run an iterator through the set just before the contains(). It confirms that the set does in fact have this element and it uses the equals() method to confirm. The output verifies that.
H Blogg wrote:What also seems odd is that when I debug the method I see equals() being called before the contains() but I don't see equals() being called during the contains(). I thought the contains() method used the equals() method to do the comparison. Even if for some reason it was using the default Object equals(), it still should return true as this is a simple circular linkage.
Jeanne Boyarsky wrote: (I didn't see where you posted about the output. It was probably in there though; it's a long post)
Jeanne Boyarsky wrote:I suspect the hashCode has a problem, but I don't see what.
Jeanne Boyarsky wrote:I'm going to move your post to Java in General where our hash code experts hang out. If this winds up being about JPA, I can move it back. I think you are more likely to get a resolution in Java in General at this point.