This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
These methods are making comparison between 2 objects based on their properties. I would like to achieve the same thing in an identical compound class (@IdClass) based on at least 4 or more properties. ie firstname, surname, dob and sex.
Joined: Oct 20, 2006
Could anyone provide some suggestion on how this could be done?
Jack, There's nothing EJB specific about these methods. They are just normal Java equals() and hashCode() methods. Note that EqualsBuilder provides dynamic implementations so you don't have to write your own.
I don't like the looks of "if (obj == this) return true;" inside of equals() method, it seems like a bad idea.
Other than that, this really is not an EJB issue, its more of a general java question, so I'm moving it to Java Intermediate. You should read up on equals() methods. Usually in a database environment you have a unique primary key (String, Integer, or Long) that unique determines the object. [ May 29, 2008: Message edited by: Scott Selikoff ]
Scott Selikoff: I don't like the looks of "if (obj == this) return true;" inside of equals() method, it seems like a bad idea.
What don't you like about that? That seems to be a pretty common idiom in equals comparisons, a shortcut that says comparing this object to itself for equality will always return true. That seems logical.
Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them. - Laurence J. Peter
You have a fundamental issue here. The object is not immutable, the hashcode value is taken from the values of the "name" fields. If someone constructs an instance, sets the names, and puts it in a HashMap, then changes the name, you will never find it in the Hash again.
This will cause subtle and evil bugs. And can lead to memory leaks.
The protoype in java.lang.Object hints that you can do this, as long as the calculation of hashCode() is changed whenever equals() would change. But I've found, the hard way, that this is dangerous.
As Bill's example shows, using sex is not a very useful thing to include in a hashCode().
In fact, using sex is rarely useful in hashCode or database indexes, It doesn't restrict the population well. Its usually more effort to calculate, maintain, etc. the field than it saves in your application. This can be worse in some domains, such as soldiers, who are nearly always male.
Joined: Oct 20, 2006
Can you confirm whether using EqualsBuilder and HashCodeBuilder below is equivalent to my own set of methods shown earlier, in addition to any alleviating unforseeing nasty surprises that you have already covered: