StringBuffer doesn't override equals(); its equals() method is the one inherited from java.lang.Object, which returns true if and only if "==" would be true. String, on the other hand, does override equals(); its definition returns true of the two objects contain the same sequence of characters.
It's false because that's how StringBuffer is defined. In fact, per my review of the API, it does not appear that StringBuffer overrides the equals method from Object as String does. If instead you want to compare Strings held by the two StringBuffers, you could do:
I dont think (IMHO) it has got to do anything with being mutable or immutable. In my opinion, StringBuffer and StringBuilder are temporary buffers to hold a string while it is in its construction phase - not the finished product. You generally do the comparison operations only at the end or beginning of a string construction, not in-between (again, just my opinion). Hence the creators of StringBuffer and StringBuilder classes might have decided against overriding equals() method.
I think Dawn is right. These classes are in 90+% of the times used as temporary storage, as a way of building a String (hence the name StringBuilder) more efficiently than using String concatenation. The intermediate results are mostly just that - intermediate results, not important. If you still need to check the contents you can use a simple utility method:
Because it uses CharSequence it accepts not just StringBuffer and StringBuilder but others like String as well. You can then call it as
Hello here is little bit demonstration about your question hopeful it may helpful for you,
String Buffer's equals method returns true only when a String Buffer
object is compared with itself. It returns false when compared with any
other String Buffer, even if the two contain the same characters. This
is actually quite a sensible behavior. However, the meaning of equals
is unfortunately not defined very well, and it is inconsistently used
across the Java A PI, so this is a bit confusing.
To compare the String objects that are produced by the String Buffer
objects in their current state, use s1.to String().equals(s2.to String())
Yogesh Gnanapraksam wrote:I too feel mutable/immutable is a point to be considered.
I disagree. java.util.Date is mutable but it has overridden equals. Likewise for many other classes, especially in the Collections framework. ArrayList is highly mutable, just as mutable as StringBuilder / StringBuffer, yet it has an overridden equals method (actually inherited from AbstractList).
The explanation which I read somewhere on the Sun site is that StringBuilder is designed to change rapidly and we don't want the intermediate stages to be compared. Exactly what Dawn and Rob said earlier.
I presume beginners realise one can work out whether the equals() method is overridden: if it is, it appears under "methods", but if not it appears under "methods inherited from Object."
Aftab Ahmad khan
posted 10 years ago
Thank you Mr Campbell Ritchie....
Yes Dawn and Rob are absolutely right,you know every buddy have there own way how they explain, well i appreciate coderanch members, they are doing awesome job so for you guys...
S.E, NEXT TECH SOLUTION USA
posted 10 years ago
30 seconds to difuse a loaf of bread ... here, use this tiny ad: