ID:4 SCJP Question of the day : Thursday June 10 2010

[Abhinav Yadav]

What should be the output of the following program:

 /**
 *
 * @author abhinav
 */
public class hello
   {
     public static void main(String args[])
      {
        String a="ThatsGood";
          StringBuilder b=new StringBuilder(a);
            String c =new String(a);
              System.out.println((a.hashCode()==b.hashCode())+" "+(a.hashCode()==c.hashCode()));
               
       }
   }

Note:There are no compilation errors.

Reference to Rules

[Emanuele Ghe]

Hi,
the best thing for you is to try the program yourself in spite of making this kind of posts.

You will learn a lot more trying things in spite of asking.

You should ask only when, even trying, you can't understand something, or you need some kind of clarification.

[Abhinav Yadav]

Emanuele Ghe wrote:Hi,
the best thing for you is to try the program yourself in spite of making this kind of posts.

You will learn a lot more trying things in spite of asking.

You should ask only when, even trying, you can't understand something, or you need some kind of clarification.

hi ,
i have tried and understood the program,the basic idea to give this question was to make other aspirants aware of concepts that are minute and sometimes can be missed thereby just running the program and getting the answer wont help until it is not understood.Trying this program without compiling would let you know the depth of concepts,thats it ,if it does any harm to post an important question then i would rather post these good questions under some another tagline.

[Sahil Kapoor]

Emanuele Ghe wrote:Hi,
the best thing for you is to try the program yourself in spite of making this kind of posts.

You will learn a lot more trying things in spite of asking.

You should ask only when, even trying, you can't understand something, or you need some kind of clarification.

Respected sir, this concept was initiated by me...and i think you may not be aware of it....this is to help others to know the concept !!! and i think most are liking it !!!

[Sahil Kapoor]

@abhinav yadav ...Please do continue with your efforts..... Thanks for the encouragement of the concept

Indeed it is a good question and i am unable to answer it.

But it think it is false false as all are different objects....I am not sure

[Sahil Kapoor]

Emanuele Ghe wrote:Hi,
the best thing for you is to try the program yourself in spite of making this kind of posts.

You will learn a lot more trying things in spite of asking.

Moreover , when someone like to post any question before asking it from others , he/she tries to make it as challenging as possible, which makes him/her to delve into the topic and try out new things , ultimately he/she comes up with something which makes him/her to learn new thing at first place.
and when he/she posts that question , its disussion would propagate the idea to others too.

[Peter Taucher]

Doesn't the hashCode method of String base on it's content? And I think StringBuilder doesn't provide an implementation of hashCode, so it uses Object's method. Therefore the result should be 'false true'.

[Abhinav Yadav]

Its ok Sahil....

[Abhinav Yadav]

Peter Taucher wrote:Doesn't the hashCode method of String base on it's content? And I think StringBuilder doesn't provide an implementation of hashCode, so it uses Object's method. Therefore the result should be 'false true'.

Hmm i think You are right,but let others also do the work.
and @sahil your answer is not correct.

[L. Wei]

false true.

First == returns false because a is not able to compare with b because they are not the same type. They are two different animals. For example,
String a = "abc";
StringBuilder b = new StringBuilder("abc");
a.equals(b); // will cause compile error, they are two types, not comparable.

Since not comparable, the hashCode() of them are definitely not indentical.

Second == returns true because a.equals(c) returns true. They belong to the same String type. They are comparable. Since a is meaningfully equals to c, their hashCode() must be identical. This's the reason why the second == returns true.

[Edwin Dalorzo]

Fist of all, we must set clear that two different objects may have the same hash code.

The definition of hashCode() method in Javadocs clearly states that "as much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects.".

Which basically means two different objects may have the same hashCode. However, the hashCode() and equals() definition in Javadocs guarantees that if equals() returns true, than the hashCode() of the two objects being compared should be the same.

That being said, we know that StringBuilder does not override neither equals() nor hashCode(), but String does. Therefore, we know that the hashCode() for two equal Strings must be the same. Therefore, the second hashCode comparison must always be true.

We cannot tell if the first hashCode comparison will produce true or false, since it is comparing two different objects. The classical implementation of hashCode in object is to return the objects memory address. If by chance this number corresponded with the hashCode generated by String based on its containing characters, then the comparison would yield true, otherwise false.

[Sahil Kapoor]

Eventually , Please do verify that
Is this assertion correct after reading above posts :-

We cannot say anything about the hashcode values of Different Objects unless they are Strings which overrides equals() method, and if two objects are equal then they must have same hashcode values.

[Abimaran Kugathasan]

Edwin Dalorzo wrote:Fist of all, we must set clear that two different objects may have the same hash code.

The definition of hashCode() method in Javadocs clearly states that "as much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects.".

Which basically means two different objects may have the same hashCode. However, the hashCode() and equals() definition in Javadocs guarantees that if equals() returns true, than the hashCode() of the two objects being compared should be the same.

That being said, we know that StringBuilder does not override neither equals() nor hashCode(), but String does. Therefore, we know that the hashCode() for two equal Strings must be the same. Therefore, the second hashCode comparison must always be true.

We cannot tell if the first hashCode comparison will produce true or false, since it is comparing two different objects. The classical implementation of hashCode in object is to return the objects memory address. If by chance this number corresponded with the hashCode generated by String based on its containing characters, then the comparison would yield true, otherwise false.

Yup, Two Different object may return the same integer values. And the Object class' hashCode() method will return the int value of the memory address of the object being compared! But the range of the 'int' is 32 bit wide, the object's memory address is depends on the internal architecture of the JVM, So it can be more than 32 bit, By this problem, two different object(may be from different class) can have the same hashcode values.

If the corresponding class overrides the hashCode() method, it should also override the equals() method as well, with the consideration of the equals contract and the hashCode contract!

[Abimaran Kugathasan]

And thanks, From this question, I got that hashCode() method is not being overrien in the StringBuffer class.

Thanks to all for this effort!

[Martin Vanyavchich]

L. Wei wrote:
String a = "abc";
StringBuilder b = new StringBuilder("abc");
a.equals(b); // will cause compile error, they are two types, not comparable.

equals takes Object as an argument. This compiles and runs fine. Some IDEs will give you a warning.