StringBuffer doubt

[saiganesh44]

Hi,

Got a doubt in StringBuffer class.

Why doesn't it implement the equals method like String class does?

[Jeeva7]

Hi

The purpose of String and StringBuffer are different.
StringBuffer doesn't extends String, if it extends then we can expect the same behavior
Both extends Object class

verify java API
String class implements comparable class so u can use equals method
StringBuffer doesn't extend comparable class so no point in talking with comparing two stringBuffer object like string

String every time creates new object and it replaces the new one with the old one -> waste of memory
String buffer doesn't create any new object it modifies the existing one -> no waster of memory

Thanks
Jeeva

[pbrockway2]

Both classes respect the documented behaviour of equals(), so to that extent, they're the same.

Exactly what equals() does is up to whoever writes the class (as with any method) and I imagine they want the methods to be expressive and useful.

StringBuffer whiteboard1 = new StringBuffer("foo");
StringBuffer whiteboard2 = new StringBuffer("foo");

So, I have two different whiteboards with the same thing written on them. And I can express precisely that with Java: different (nonequal) whiteboards, but the same (equal) string contents.

Personally I find the choice of implementation here quite natural because I wouldn't regard whiteboards as being equal in any significant sense just because they happen to have the same word written on them.

Whiteboards are mutable in the sense that they can change their contents - a teacher can erase the contents and reuse the same whiteboard where "the same" means "the whiteboard in such-and-such a room". The student, on the other hand, wants to be careful and copy exactly what the teacher has written where "exactly" has the meaning "the same characters in the same order". In ordinary life we use both semantics when dealing with written language.

Nothing is lost with this different semantics for whiteboards (with its stress on the container rather than the contained) because if I want to I can evaluate

whiteboard1.toString().equals(whiteboard2.toString())

[pbrockway2]

verify java API
String class implements comparable class so u can use equals method
StringBuffer doesn't extend comparable class so no point in talking with comparing two stringBuffer object like string

In fact equals() is declared in the Object super class, so it is a method-in-good-standing of both String and StringBuffer. That String implements the Comparable interface is largely irrelevant (but see the comments at the start of the API docs of that interface for the conditions that String's implementation of equals() should - and does - meet.)

It does make sense to compare StringBuffer instances for equality (and whiteboard1.equals(whiteboard2) works fine): just not on the basis of what their contents happen to be at some instant.

[saiganesh44]

Both classes respect the documented behaviour of equals(), so to that extent, they're the same.

Exactly what equals() does is up to whoever writes the class (as with any method) and I imagine they want the methods to be expressive and useful.

StringBuffer whiteboard1 = new StringBuffer("foo");
StringBuffer whiteboard2 = new StringBuffer("foo");

So, I have two different whiteboards with the same thing written on them. And I can express precisely that with Java: different (nonequal) whiteboards, but the same (equal) string contents.

Personally I find the choice of implementation here quite natural because I wouldn't regard whiteboards as being equal in any significant sense just because they happen to have the same word written on them.

Whiteboards are mutable in the sense that they can change their contents - a teacher can erase the contents and reuse the same whiteboard where "the same" means "the whiteboard in such-and-such a room". The student, on the other hand, wants to be careful and copy exactly what the teacher has written where "exactly" has the meaning "the same characters in the same order". In ordinary life we use both semantics when dealing with written language.

Nothing is lost with this different semantics for whiteboards (with its stress on the container rather than the contained) because if I want to I can evaluate

whiteboard1.toString().equals(whiteboard2.toString())

Thanks a lot, that explained well.

[pbrockway2]

You're welcome.

[Tolls]

I suspect part of it is also to discourage people from simply using StringBuffer/Builder in place of Strings.
You may think this is unlikely, but I've seen more than one person put this forward so that they could change String values "easily".