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

[Arijit Daripa]

public class Equality{
public static void main(String[] args){
    StringBuffer sbf1 = new StringBuffer("x");
    StringBuffer sbf2 = new StringBuffer("x");
    System.out.println(sbf1.equals(sbf2)); // false
    
    StringBuilder sbd1 = new StringBuilder("x");
    StringBuilder sbd2 = new StringBuilder("x");
    System.out.println(sbd1.equals(sbd2)); // false
}
}

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

[Mohammad Khan]

No reply so far !
Alright lets put this in different way,

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

[Arijit Daripa]

Mohammad! I am taking your quote as the title of this thread.
let's hope, we shall have, at least, one reply.

[Seema Gaurav]

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]

Yeah, i think that can be a reason.
StringBuffer is mutable whereas String and Wrapper class are immutable.

[Seema Gaurav]

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]

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]

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]

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]

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]

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]

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]

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.

       //Start of manipulation work		
       StringBuilder stringbuilder = new StringBuilder("Line 1");
       stringbuilder.append("Line 3");
       String lineToInsert = "Line 2";
       int index = stringbuilder.indexOf("Line 3");
       stringbuilder.insert(index, lineToInsert);
       //End of manipulation work		

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]

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]

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.

 String str = "akash kumar";   

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

 String str = akashvar + kumarvar;   

it will be compiled to this...

 String str = new StringBuilder().append(akashvar).append(kumarvar).toString();   

Henry

[akash kumar]

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]

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]

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]

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.

        String stringOne = new String("string");
        String stringTwo = new String("string");
        
        System.out.println(stringOne.equals(stringTwo));
        System.out.println(stringOne==stringTwo);

Output:
true
false

[akash kumar]

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]

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".