Difference between Object's equals() and String's equals() method ?

[Praveen Kumar]

Hi


StringBuffer does not overide the equals() method but it gets from Objects method ?

Is there any diff between Object's equals() and String's equals() method ?

Thanks In Adavance

Praveen

[Rodrigo Lopes]

Check it:
From Object class (version 1.5.0_14):

    public boolean equals(Object obj) {
return (this == obj);
    }

From String class (version 1.5.0_14):

    public boolean equals(Object anObject) {
if (this == anObject) {
    return true;
}
if (anObject instanceof String) {
    String anotherString = (String)anObject;
    int n = count;
    if (n == anotherString.count) {
char v1[] = value;
char v2[] = anotherString.value;
int i = offset;
int j = anotherString.offset;
while (n-- != 0) {
    if (v1[i++] != v2[j++])
return false;
}
return true;
    }
}
return false;
    }

[Joanne Neal]

You can find the source code for the Java API classes in a file called src.zip in your JDK installation directory. Have a look at the code for the String class and you will get the answer.

[imaya Munusamy]

Originally posted by Joanne Neal:
You can find the source code for the Java API classes in a file called src.zip in your JDK installation directory. Have a look at the code for the String class and you will get the answer.

I couldn't imagin any reason why Stringbuffer has not implemented equals method....it will break if we use String buffer in HashMap or HashSet.. can some one explain it

[Joanne Neal]

Originally posted by imaya M:


I couldn't imagin any reason why Stringbuffer has not implemented equals method....it will break if we use String buffer in HashMap or HashSet.. can some one explain it

That question is being discussed here
[ May 29, 2008: Message edited by: Joanne Neal ]

[Campbell Ritchie]

The explanation is that StringBuilder and StringBuffer are expected to change their values repeatedly, so equality based on content would change.

You can always say
if (builder.toString().equals(otherBuilder.toString())) . . .

[imaya Munusamy]

Originally posted by Campbell Ritchie:
The explanation is that StringBuilder and StringBuffer are expected to change their values repeatedly, so equality based on content would change.

You can always say
if (builder.toString().equals(otherBuilder.toString())) . . .

In case of if condition we can check like this but if you use Stringbuffer as key in HashMap it will break

[Campbell Ritchie]

Please, "Imaya M," read the Map interface API documentation. It tells you about changing keys in a Map.

And please take notice of what I told you in the private message.
[ May 29, 2008: Message edited by: Campbell Ritchie ]

[imaya Munusamy]

Changing value of key will affect in hashMap but that has to be taken care by developer. this should not be the reason for not implementing equal method in StringBuffer class.

[Paul Sturrock]

Originally posted by imaya M:


In case of if condition we can check like this but if you use Stringbuffer as key in HashMap it will break

No, it won't. The Map will work as expected. It will match based on the equals() method defines in the Object class. If you were expecting it to work based on the value this would be a misreading of the JavaDocs on your part.

[Jim Yingst]

To clarify my previous post here (see why we don't like these discussions spread across multiple threads? Blech!):

If you use a StringBuffer as a key, with the equals as defined, and you change the value inside the StringBuffer, then the map won't break, but quite possibly it won't behave as you expect. In fact that was the point of this thread - with the current equals() and hasnCode() implementation, HashMap doesn't work as many would expect. I can imagine little use for a HashMap using StringBuffers as keys. It's not broken, just not very useful.

However if Sun had provided an equals() and hashCode() that reflect "expected" behavior (based on the content of the StringBuffer), then if you changed the content of a StringBuffer used as a key, that would break the contract of the HashMap, and it wouldn't work. That's really true for any mutable object that has an equals() and hashCode() based on its content. If you change the object after it's been put in a map as a key, the map won't work.

[imaya]: do you mean we should use only immutable object in Hashmap or Hashset? lot of time we 'll use our custom class (Eg: Student.class) objects as key in hashmap which is mutable which can be modified even after put in collection. developer has to take care of this.

Well, for most classes, we don't have a mutable version and an immutable version. We often just have a mutable version, and when we put instances in a map, we simply don't change them afterwards. Usually that works, though sometimes people make mistakes. Often that seems easier than creating new immutable classes just for use as keys. Fine.

However with String and StringBuffer (and StringBuilder), we have both mutable and immutable versions. So if you need a string-like object to use as a key - USE A STRING. I don't think there is any good reason to use a mutable object as a key when an immutable alternative is readily available. The only reason to use the mutable version is if you still expect to change it - and if that's the case, you should not be using it as a key.
[ May 29, 2008: Message edited by: Jim Yingst ]

[imaya Munusamy]

Originally posted by Paul Sturrock:


No, it won't. The Map will work as expected. It will match based on the equals() method defines in the Object class. If you were expecting it to work based on the value this would be a misreading of the JavaDocs on your part.

It will definitely break if you use StringBuffer as key because the equal method is not implemented in the class it uses Object class equal method.



HashMap first check hash code to identify bucket then it uses equal method to identify the object from the bucket. as the equal method is not implemented it will call super class (object class) equal method. object class equal method check only memory address of object (obj1 == obj2) . if the StringBuffer we put initially and the one we used to get again are different object it will return null.


see the below eg:

HashMap hm = new HashMap();

StringBuffer sb1 = new StringBuffer("key1");
StringBuffer sb2 = new StringBuffer("key2");

hm.put(sb1 , "value1");
hm.put(sb2 , "value2");

//This will return null
System.out.println("Value = " + hm.get( new StringBuffer("key1")) );

//this will return value1 as we are using same object to retrive
System.out.println("Value = " + hm.get( sb1) );

[Jim Yingst]

But that's not broken, in the sense that it is still behaving exactly as you should expect, based on the API.

Regardless, I say there is no good reason to use a StringBuffer or StringBuilder as a key in a Map, ever. I can imagine cases where you could do it, but there's always another way which is no worse, and almost always better. Which usually means: USE A STRING INSTEAD.

[imaya Munusamy]

sorry Paul,
i didn't read your message properly. it will not break. it works as per javadoc.

Jim,
there is no good reason to use Stringbuffer as key. but my first question is still remains...what is the reason that the equal method is not implemented in that class.

[Campbell Ritchie]

Originally posted by imaya Munusamy:
Jim, there is no good reason to use Stringbuffer as key. but my first question is still remains...what is the reason that the equal method is not implemented in that class.

But equals() IS implemented in StringBuilder; it isnot overridden. We have already told you why it isn't overridden, and I have told you a workaround. Because StringBuilder is expected to change rapidly. You might not agree with that, but that it the reason.

[imaya Munusamy]

Originally posted by Campbell Ritchie:
But equals() IS implemented in StringBuilder; it isnot overridden. We have already told you why it isn't overridden, and I have told you a workaround. Because StringBuilder is expected to change rapidly. You might not agree with that, but that it the reason.

Yea Campbell you are right, i couldn't convince with this reason. Any method of class going to operate on current state of the object. equals also do the same thing. using equal method we are checking whether the state of two objects are same or not at that time. doesn't matter whether it 'll change or not in future.

if the state of the object changes then next time when we call the method its going to give different value.

For Eg: ArrayList class has implemented equals method. i guess ArrayList values may change more often than Stringbuffer . if that is the reason then it should not have been implemented in ArrayList also.

[Joanne Neal]

Perhaps Earnest's suggestion here is the reason.

[Campbell Ritchie]

That's a good idea, Joanne.

And Imama, I have told you, you might not agree with the decision to use the Object implementation. I don't myself, but I think we are stuck with it. I have looked on the lists of requests and bugs at Sun, and this has come up before and they are sticking by their decision. So we are stuck with it!

[imaya Munusamy]

Originally posted by Campbell Ritchie:
That's a good idea, Joanne.

And Imama, I have told you, you might not agree with the decision to use the Object implementation. I don't myself, but I think we are stuck with it. I have looked on the lists of requests and bugs at Sun, and this has come up before and they are sticking by their decision. So we are stuck with it!

campbell, Thankx for your clarification

[Campbell Ritchie]

You're welcome.