aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Why 'equals' methods were not overridden in StringBuffer and StringBuilder? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Why Watch "Why New topic
Author

Why 'equals' methods were not overridden in StringBuffer and StringBuilder?

Arijit Daripa
Ranch Hand

Joined: Aug 09, 2008
Posts: 142


What makes Java Developers not override equals() method of StringBuffer & StringBuilder classes?
[ October 01, 2008: Message edited by: Arijit Daripa ]

SCJP 5
Mohammad Khan
Ranch Hand

Joined: Sep 23, 2008
Posts: 37
No reply so far !
Alright lets put this in different way,

Why 'equals' methods were not overridden in StringBuffer and StringBuilder?
Arijit Daripa
Ranch Hand

Joined: Aug 09, 2008
Posts: 142
Mohammad! I am taking your quote as the title of this thread.
let's hope, we shall have, at least, one reply.
Seema Gaurav
Ranch Hand

Joined: Apr 29, 2008
Posts: 47
Since nobody has answered, can i guess what's happening?

As per my observation, all classes used to store data, or those that can act as instance variables - String, Wrapper Classes, Date, classes in the collection framework, etc override equals() and hashCode().

Classes like StringBuilder and StringBuffer are more like utility classes that help us manipulate Strings, maybe that's why they did not override equals() and hashcode() here.

I might be wrong, but this is what I thought of when I read this question, please feel free to correct me if I'm wrong.
thanks,
Seema
vidhya suvarna
Ranch Hand

Joined: Aug 28, 2008
Posts: 148
Yeah, i think that can be a reason.
StringBuffer is mutable whereas String and Wrapper class are immutable.


SCJP 1.4 - 88%<br />SCWCD 1.5 - Preparing
Seema Gaurav
Ranch Hand

Joined: Apr 29, 2008
Posts: 47
Hi Vidhya,
I thought of immutability to be a reason too. But there are classes like Date which are mutable but they do override hashCode() and equals().

Well, with respect to String and StringBuffer()/StringBuilder, immutability can be a factor too.

Till we hear more on this, it's good food for thought, thanks for the post, Vidhya

Seema
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

Originally posted by Mohammad Khan:
No reply so far ! ...

Wow, after 12 full minutes? With gaps like that, one might get the impression this is a forum (where patience is a virtue) rather than a real-time chat room.

I hope I'm not too late when I suggest that instances of StringBuffer and StringBuilder could be considered "works in progress." These are Strings in the making -- not a final product. It doesn't make much sense to compare things while they're still being assembled, does it?


"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer
sscce.org
Paul Yule
Ranch Hand

Joined: May 12, 2008
Posts: 229
Originally posted by marc weber:

instances of StringBuffer and StringBuilder could be considered "works in progress." These are Strings in the making -- not a final product.


I agree. Besides, more explicitly, You can always get the "value" of the String buffer with a toString and equals on that.
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

Originally posted by Paul Yule:
... You can always get the "value" of the String buffer with a toString and equals on that.

Exactly. If you need a "snapshot" of what the StringBuffer or StringBuilder contains at that moment, getting a String representation is the way to do it.
Mohammad Khan
Ranch Hand

Joined: Sep 23, 2008
Posts: 37
Originally posted by marc weber:
[QB]
Wow, after 12 full minutes? With gaps like that, one might get the impression this is a forum (where patience is a virtue) rather than a real-time chat room.

I apologize !!
akash kumar
Ranch Hand

Joined: Jun 13, 2007
Posts: 63
Paul Yule wrote:
Originally posted by marc weber:

instances of StringBuffer and StringBuilder could be considered "works in progress." These are Strings in the making -- not a final product.


I agree. Besides, more explicitly, You can always get the "value" of the String buffer with a toString and equals on that.


Hi marc!

Even I don't understand Why 'equals' methods were not overridden in StringBuffer and StringBuilder.

I feel like equals method in StringBuffer and StringBuilder are dangling methods which doesn't serve it's purpose.

I could agree that StringBuffer and StringBuilder could be considered as "works in progress". But at some point of time the work should be over and it should contain values which we can use, so that we can use most often used methods such as equals(). Hence considering it always to be "works in progress" doesn't make any sense to me and i don't agree.

When I say I don't agree I mean I want little more explanation to understand it to agree.


Seetharaman Venkatasamy
Ranch Hand

Joined: Jan 28, 2008
Posts: 5575

marc weber wrote:instances of StringBuffer and StringBuilder could be considered "works in progress." It doesn't make much sense to compare things while they're still being assembled


Excellent
akash kumar
Ranch Hand

Joined: Jun 13, 2007
Posts: 63
seetharaman venkatasamy wrote:
marc weber wrote:instances of StringBuffer and StringBuilder could be considered "works in progress." It doesn't make much sense to compare things while they're still being assembled


Excellent


Hi seetharaman! I don't understand how instances of StringBuffer and StringBuilder could be considered "works in progress" whole through its life time.


Now after the manipulation why shouldn't we use stringbuilder content for comparisons?

What my understanding is Strings are immutable objects meant for storing strings, not ideal for manipulations as it would require creating, copying, and destroying lot of intermediate String objects. StringBuffer and StringBuilder are ideal for manipulations as they are mutable objects and hence can be used for manipulating and storing the strings. If I go by marc's statement aren't StringBuffer and StringBuilder ideal for storing strings but are only ideal for string manipulations? If not ideal for storing strings why so?

Please I need more explanation to understand it.
Seetharaman Venkatasamy
Ranch Hand

Joined: Jan 28, 2008
Posts: 5575

akash kumar wrote:Hi seetharaman! I don't understand how instances of StringBuffer and StringBuilder could be considered "works in progress" whole through its life time.


StringBuilder is Designed to ba a Mutable Object to avoid Creation of unnecessary Objects.

Example :

Concatenate the objects in String is worst instead use StringBuffer
String str = "akash " + "kumar" //which will create 3 objects

where as StringBuilder sb = new StringBuilder("akash"); sb.append("kumar");//which will create 1 object
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 19063
    
  40

seetharaman venkatasamy wrote:
Concatenate the objects in String is worst instead use StringBuffer
String str = "akash " + "kumar" //which will create 3 objects


Actually, this is not true.

Both "akash" and "kumar" are literals (hence, compile time constants). And concat of compile time constants is still a compile time constant. Hence, the compiler will compile the code as if it was this.



Furthermore, string concats are syntactic sugar. So, even if it wasn't a compile time constants, such as this...



it will be compiled to this...



Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
akash kumar
Ranch Hand

Joined: Jun 13, 2007
Posts: 63
seetharaman venkatasamy wrote:
akash kumar wrote:Hi seetharaman! I don't understand how instances of StringBuffer and StringBuilder could be considered "works in progress" whole through its life time.


StringBuilder is Designed to ba a Mutable Object to avoid Creation of unnecessary Objects.

Example :

Concatenate the objects in String is worst instead use StringBuffer
String str = "akash " + "kumar" //which will create 3 objects

where as StringBuilder sb = new StringBuilder("akash"); sb.append("kumar");//which will create 1 object


Hi seetharaman! It seems you have not read my earlier post fully. I already understand what you are trying to say.

akash kumar wrote:
What my understanding is Strings are immutable objects meant for storing strings, not ideal for manipulations as it would require creating, copying, and destroying lot of intermediate String objects. StringBuffer and StringBuilder are ideal for manipulations as they are mutable objects and hence can be used for manipulating and storing the strings.


Please read my post fully.
Seetharaman Venkatasamy
Ranch Hand

Joined: Jan 28, 2008
Posts: 5575

Henry wrote:
String str = akashvar + kumarvar;
it will be compiled to this...
String str = new StringBuilder().append(akashvar).append(kumarvar).toString();


Thanks Henry for your good explanation . i thought of stringbuffer is use instead of the string concatenation . but as per your example, there is no difference right?
KrishnaPrasad raghavan
Ranch Hand

Joined: Oct 28, 2008
Posts: 46
Hi,

Lets take for example
StringBuffer sb1 = new StringBuffer("ABC");
StringBuffer sb2 = new StringBuffer("ABC");


The reference variable sb1 contains some reference to where the new StringBuffer() is residing. Hence has nothing to do with the value "ABC" inside the new StringBuffer. Similarly sb2 will also contain some reference to where the new StringBuffer("ABC") is located. (Think Objects).

Hence sb1.equals(sb2) will never be the same as it is pointing to two different references.

sb1.toString().equals(sb2.toString()) would make sense as it is comparing the value.

I guess the same applied for StringBuilder. My thoughts. StringBuffer is a subclass of Object which has the .equals() method. Correct me if I am wrong here.
akash kumar
Ranch Hand

Joined: Jun 13, 2007
Posts: 63
KrishnaPrasad raghavan wrote:
Hence sb1.equals(sb2) will never be the same as it is pointing to two different references.


The references can be different but the values can be same. The equals() method is meant to be used for comparing the values(or logically equivalent instances) and not the reference. But it's up to the developer to override the equals() method and provide the necessary functionality.



Output:
true
false

akash kumar
Ranch Hand

Joined: Jun 13, 2007
Posts: 63
KrishnaPrasad raghavan wrote:Hi,
sb1.toString().equals(sb2.toString()) would make sense as it is comparing the value.


The toString() method returns the String object.
So sb1.toString().equals(sb2.toString()) would result to someStringObject.equals(someAnotherStringObject)
KrishnaPrasad raghavan
Ranch Hand

Joined: Oct 28, 2008
Posts: 46
Akash Kumar wrote :
"The equals() method is meant to be used for comparing the values(or logically equivalent instances) and not the reference. ".


Yes I agree. I am not able to make sense why this contract is not implemented in the "StringBuffer" or "StringBuilder".
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Why 'equals' methods were not overridden in StringBuffer and StringBuilder?