Hey,

I know that this is the most popular discussion, so sorry for raise it again.

In my application the objects are equals if they are equals in all the fields (except ID).

So few questions:
1. Do i need to check equals on all the fields include references, collections and etc.
I looks on equals example and didnt saw that reference and collection was compared, what is the reason for this? lets say i have a user that has a reference to an Address . the users are not equals if the address that they point is not equal.

2. Lets say i have class B that inherit from A class B has no primitive fields (only additional references) how the equals of B need to look like ?
What about B - hashCode function (is not seem resonable to call to super in the hashcode) ?

Thank you

1. You need to do whatever your business rules require. If it only takes 1 field to differentiate, or all of them. If there is no way to tell that a user isn't the same w/o checking out his address in another table, then put address in your .equals. Just be warned of the implications when it comes to lazy loading and session management when you implement this. There isn't a set formula, just normal guidelines.

A good way to define your equals and hashcode methods is to use attributes that won't normally change in the object's lifetime of being in memory. If these attributes DO change, which is fine, delete it, make a new one, and update references to point to the new one; or make sure you change them in a safe context, where the object is protected somehow so another part of your program isn't using it.

2. I would say it is reasonable to call super in B's hashcode if it doesn't have any of its own identifying features. However, I have to question why you have B extending A if B doesn't have its own identifying features. If the only way to differentiate two classes that extend the same class exist in A, you have to use A's equals/hashcode methods or write some custom ones.

It seems to much to check all the object graph for equals,
but it also seems insufficent to chek only object field without check his references.

Thank you

ORM required that you implement equal.

You can write the equal based on the version or the orm id because one of the objects (or both) is transetive, so it dosnt has orm id , but it equal to the other object (which was already saved).

Lets discuss on the example i gave. As i understand equal the user is not equal to the other user if the address that they point to it is not the same,

But i saw a lot of java code exapmles and no one check the reference in the equal.

Why?