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 Difference between Object's  equals() and String's  equals()  method ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Difference between Object Watch "Difference between Object New topic
Author

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

Praveen Kumar
Ranch Hand

Joined: Nov 06, 2006
Posts: 133
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
Ranch Hand

Joined: Feb 29, 2008
Posts: 119
Check it:
From Object class (version 1.5.0_14):

From String class (version 1.5.0_14):
Joanne Neal
Rancher

Joined: Aug 05, 2005
Posts: 3645
    
  15
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.


Joanne
imaya Munusamy
Greenhorn

Joined: May 19, 2008
Posts: 20
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
Rancher

Joined: Aug 05, 2005
Posts: 3645
    
  15
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
Sheriff

Joined: Oct 13, 2005
Posts: 39387
    
  28
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
Greenhorn

Joined: May 19, 2008
Posts: 20
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
Sheriff

Joined: Oct 13, 2005
Posts: 39387
    
  28
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
Greenhorn

Joined: May 19, 2008
Posts: 20
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
Bartender

Joined: Apr 14, 2004
Posts: 10336

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.


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
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 ]

"I'm not back." - Bill Harding, Twister
imaya Munusamy
Greenhorn

Joined: May 19, 2008
Posts: 20
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
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
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
Greenhorn

Joined: May 19, 2008
Posts: 20
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
Sheriff

Joined: Oct 13, 2005
Posts: 39387
    
  28
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
Greenhorn

Joined: May 19, 2008
Posts: 20
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
Rancher

Joined: Aug 05, 2005
Posts: 3645
    
  15
Perhaps Earnest's suggestion here is the reason.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39387
    
  28
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
Greenhorn

Joined: May 19, 2008
Posts: 20
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
Sheriff

Joined: Oct 13, 2005
Posts: 39387
    
  28
You're welcome.
 
Don't get me started about those stupid light bulbs.
 
subject: Difference between Object's equals() and String's equals() method ?