• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
  • paul wheaton
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Henry Wong
Saloon Keepers:
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Tim Moores
  • Mikalai Zaikin
Bartenders:
  • Frits Walraven

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

 
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ]
 
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Sheriff
Posts: 11343
Mac Safari Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
Ranch Hand
Posts: 230
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Mac Safari Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 !!

 
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.


 
Ranch Hand
Posts: 5575
Eclipse IDE Windows XP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 Windows XP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
author
Posts: 23958
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 Windows XP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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".
 
We can walk to school together. And we can both read this tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
reply
    Bookmark Topic Watch Topic
  • New Topic