equals and hashcode..

[andy armstrong]

Just to confirm there have been a lot of places
in the notes where people have said you must
implement these functions for your primary key.
This is not the case!! You in fact should but it is not a must. You must have a no-arg constructor..
As well you should not even use the equals method
to determine equality but the isIdentical method.
Any comments..

[Alberto Dell'Era]

Originally posted by andy armstrong:
Just to confirm there have been a lot of places
in the notes where people have said you must
implement these functions for your primary key.
This is not the case!! You in fact should but it is not a must. You must have a no-arg constructor..
As well you should not even use the equals method
to determine equality but the isIdentical method.
Any comments..

Quoting from the EJB Specification 2.0:
"10.6.13 Entity bean?s primary key class
The Bean Provider must specify a primary key class in the deployment descriptor.
The primary key type must be a legal Value Type in RMI-IIOP.
The class must provide suitable implementation of the hashCode() and equals(Object
other) methods to simplify the management of the primary keys by the Container."
So definitely you have to provide the implementation of the equals (Object) and hashCode() for your Primary Key class. Of course, if you use e.g. java.lang.String for your PK, that two methods are already implemented in a suitable way.
That is not surprisingly, since the default implementation of the equals(Object) method (inherithed from java.lang.Object) is to compare the "this" references of the two objects, so two PK objects with identical values would be always different (!) ...
Try this:

  

public class CustomerName  {
        public String z;
        public static void main (String [] args) {
                CustomerName h1 = new CustomerName();
                CustomerName h2 = new CustomerName();
                h1.z = h2.z = "James Gosling";
                System.out.println (h1.equals(h2)); // prints "false" (!!!)
        }
}
~

So you won't find your PK in an array even if it's there, even if you use the straighforward method of looping on the array comparing each element to your PK with the equals method - a thing that any client, not to mention the container, would definitely think it's safe to do.
This is much better:

public class CustomerName  {
        public String z;
        public boolean equals(java.lang.Object rhs) {
                if (rhs instanceof CustomerName == false)
                        return false;
                return this.z == ((CustomerName) rhs).z;
        };
        public static void main (String [] args) {
                CustomerName h1 = new CustomerName();
                CustomerName h2 = new CustomerName();
                h1.z = h2.z = "James Gosling";
                System.out.println (h1.equals(h2)); // prints "true"
        }
}

Similar considerations apply for hashCode(); if you don't implement it correctly, you will have surprising results (such as adding your PK to a Collection and not finding it in the Collection immediately afterwards - even if it's there ...).
A *GREAT* dissertation on the subject is contained in "Effective Java" by Joshua Bloch, the best book on robust Java Programming that I've ever read.

[Chris Mathews]

Your primary key must override both equals() and hashCode() to act appropriately. All Java classes have an implementation of equals() and hashCode() (from Granddaddy Object) but this base implementation is useless for our purposes. If you don't override equals() and hashCode() then you are going to get some very wierd and incorrect functionality. There is not compile-time or deployment-time checking that prevents you from not overriding these methods but it is stated in the spec that you must.
EJB 2.0 Specification 10.6.13

The class must provide suitable implementation of the hashCode() and equals(Object other) methods to simplify the management of the primary keys by the Container.

The implementation inherited from Object does not fulfill the requirement for a "suitable implementation".

[Chris Mathews]

Hey Alberto, you beat me to the punchline.

[Alberto Dell'Era]

Originally posted by Chris Mathews:
Hey Alberto, you beat me to the punchline.

Next time we should synchronize the starting time ...