File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Beginning Java and the fly likes Strings Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Strings" Watch "Strings" New topic
Author

Strings

K Kiran Kumar
Ranch Hand

Joined: Jan 04, 2006
Posts: 109
Hi When I use the following code,

String s="cow";
String c="cow";
String s1=new String("cow");
String s2=new String("cow");
System.out.println(s1==s2);//false
System.out.println(s==s1);//false
System.out.println(s==c);//true
System.out.println(s.hashCode());//1000911
System.out.println(s1.hashCode());//1000911
System.out.println(s2.hashCode());//1000911
System.out.println(c.hashCode());//1000911

As per my understanding, if we use ==, the control will check for references but not for objects. But why is that in the above example, s1==s2 is false, eventhough they have the same hashCode? Strings are immutable and when a new string is initialised, the control checks for the existing strings in the string pool and if it matches the existing one with the new one, then the control will assign the new variable to the existing string object. So I should get true when I use s1==s2 since their hashcodes are equal. But I am getting false.

Any explanation on this issue why we are getting false will be appreciated.

Regards,
Kiran.
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

Not an advanced question. Moving...


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Joanne Neal
Rancher

Joined: Aug 05, 2005
Posts: 3742
    
  16
The line creates a new String object and assigns the value "cow" to it. You therefore have two objects - the String literal "cow" which is in the String pool and the new Object that you have just created. As they are two different objects the == test will return false.

Two different objects can have the same hashcode. The hashCode() method is only required to guarantee that two objects that are equal will both return the same hashCode. It does not have to guarantee that two different objects return different hashcodes.


Joanne
K Kiran Kumar
Ranch Hand

Joined: Jan 04, 2006
Posts: 109
But as per the definition, the hashCode() returns the memory address of that particular object. So all the four hashCode System.out.println() are giving same hashCode values i.e., the same location. Since == will check for reference, then s1==s2.

Moreover as per Strings immutability concept, first the control will check in the String pool in VM whether this string is there or not and if it is there, then the reference is pointed to the string obj. So now all the four references are pointing to the same obj(evident from their hashCodes)
I am still not clear with your argument. Can you please provide further explanation to this please....
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336


But as per the definition, the hashCode() returns the memory address of that particular object.

Where did you get this definition from?
Joanne Neal
Rancher

Joined: Aug 05, 2005
Posts: 3742
    
  16
Originally posted by Paul Sturrock:

Where did you get this definition from?


Probably from the Javadoc for the Object class
As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)


@OP - the hashCode method is overridden in the String class
The hash code for a String object is computed as
s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]
using int arithmetic, where s[i] is the ith character of the string, n is the length of the string, and ^ indicates exponentiation. (The hash value of the empty string is zero.)
K Kiran Kumar
Ranch Hand

Joined: Jan 04, 2006
Posts: 109
Hi Paul,
I got the hashCode() definition from the following link...
http://java.sun.com/docs/books/tutorial/java/IandI/objectclass.html

Hi Joanne,

So as per your explanation, hashCode() does not the exact memory address and memory address is involved in generating hashCode().

If we override equals() method, then why should we override the hashCode()?
Even if I don't override hashCode(), I will still get the output that I want from equals() overridden definition when comparing two objects. Is the overridden of hashCode() is done because of definition? and not for anything else(if two objects are equal, then their hashCode() must be equal)Please let me know.

Sample example......

public class equalst
{
int a;
String b;
public equalst(int a,String b)
{
this.a=a;
this.b=b;
}
public static void main(String[] args)
{
equalst t=new equalst(1,"xx");
equalst t1=new equalst(1,"xx");
System.out.println(t.equals(t1));
System.out.println(t.hashCode());
System.out.println(t1.hashCode());

}
public boolean equals(Object t1)
{
equalst t=(equalst)(t1);
if ((this.a==t.a) && ((this.b).equals(t.b)))
return true;
else
return false;
}
}
Joanne Neal
Rancher

Joined: Aug 05, 2005
Posts: 3742
    
  16
You don't have to override the hashcode method, but if you don't then you will not be able to use instances of your class in any situation where the hashCode method is called, e.g. as a key in a HashMap.

The reason that Hashmaps call the hashCode method is that it is quicker to compare two ints than it is to compare two objects. So, if obj1.hashCode() != obj2.hashCode(), there is no need to call the equals method.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Strings