Re: Comparing objects with == (Legacy Java Answers Forum)

Legacy Java Answers Forum
December 2001

This page contains an archived post to the Java Answers Forum made prior to February 25, 2002. If you wish to participate in discussions, please visit the new Artima Forums.

Message:

Re: Comparing objects with ==

Posted by Brian Sanders on December 05, 2001 at 3:52 PM

Let me first address your statements in terms of regular Objects, then I'll mention Strings and string literals (which are a special case).

Suppose your earlier code example were slightly rewritten like this:


Integer one = new Integer(3);
Integer two = new Integer(3);
System.out.println(one == two); //"false"
System.out.println(one.equals(two)); //"true"System.out.println(one.hashCode());  //"3"
System.out.println(one.hashCode());  //"3"

Two Integer objects are created on the heap (all Java objects are created in the heap). The current stack has a reference to each of the objects in the local variables one and two. When we apply the == operator to the two variables, it evaluates to false. This is because the == operator (when applied to Objects) compares the two variables to see if they refer to the same Object on the heap. When comparing two objects for equalilty, we use the .equals() method to compare the values of the two objects.

The default implementation of the .equals() method is identical to the == operator. This is why


Object obj1 = new Object();
Object obj2 = new Object();
System.out.println(obj1.equals(obj2));

 evaluates to false.  Even though both have the same value (both are empty objects) the references are not the same.  This is why most classes in the JDK override the equals() method -- to create a comparison by value.
Now on to the hashCode() method.  A hashcode is intended to be an integer that uniquely identifies the value of the object.  For any two objects with the same value, their hashcodes should be the same.  For the Integer class, the hashcode is simply the value of the underlying int.  In the generic Object.hashCode(), the value is (usually) based on the memory address of the object on the heap.
Now about Strings.  Strings are special in Java.  Strings are "interned", which means that the String class maintains an internal pool of instances created from String literals.  The following two blocks are (functionally) equivalent:

String s1 = new String("Hello");
String s2 = s1;String s1 = "Hello";
String s2 = "Hello";

This is why the comparison "Hello" == "Hello" evaluates to true; the string literals refer to the same String object.
When you create a String object using the new keyword, the interning process is not used.  Therefore, new String("Hello") != new String("Hello")
So, in summary, and to answer your questions:
My understanding is when you apply == it is the hash codes getting copared. -- No, it is the object references
If this is true, s1.hashCode() and s3.hashCode() should return the same same result. But it is not. -- Try running your example.  They do return the same value.  This is because the String class overrides the hashCode() method to return an int that is based on the object's value.
If you're writing a custom class that you need to compare with hashCode() and equals(), be sure to override these methods.









Replies:


	Web Artima.com