This week's book giveaway is in the Clojure forum.
We're giving away four copies of Clojure in Action and have Amit Rathore and Francis Avila on-line!
See this thread for details.
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
Arijit Daripa
Ranch Hand
Posts: 142
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


What makes Java Developers not override equals() method of StringBuffer & StringBuilder classes?
[ October 01, 2008: Message edited by: Arijit Daripa ]
 
Mohammad Khan
Ranch Hand
Posts: 37
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 142
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 47
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 148
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yeah, i think that can be a reason.
StringBuffer is mutable whereas String and Wrapper class are immutable.
 
Seema Gaurav
Ranch Hand
Posts: 47
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 11343
Java Mac Safari
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Paul Yule
Ranch Hand
Posts: 229
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 11343
Java Mac Safari
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 37
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 66
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 5575
Eclipse IDE Java Windows XP
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 66
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 5575
Eclipse IDE Java Windows XP
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Pie
Posts: 20836
75
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
akash kumar
Ranch Hand
Posts: 66
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 5575
Eclipse IDE Java Windows XP
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 46
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 66
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 66
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 46
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic