• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Equals() method of StringBuffer

 
Roger Zhao
Ranch Hand
Posts: 73
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, all:
I met a question on some site, but the anwser is a big question for me.
class test {
public static void main(String[] args) {
StringBuffer sb1 = new StringBuffer("hello");
StringBuffer sb2 = new StringBuffer("hello");
if (sb1.equals(sb2))
System.out.println("equal");
else
System.out.println("not equal");
}
}
output? equal or not equal?
I chose the first with no doubt.
But....the answer is "not equal". The reason is that "The StringBuffer class does not override equals(). Hence, this class returns false when passed two different objects. " It sounds something reasonable.
I am puzzled. Who can unpuzzle it?
Thanks.
Roger
 
Anonymous
Ranch Hand
Posts: 18944
  • 0
  • send pies
  • Quote
  • Report post to moderator
Per default all objects inherit equals() from Object. The class can then override it like e.g String. In Object it is implemented but it simply
compares the passed Object with the actual object via '=='.
But '==' simply compares the object address. So when it is the same address
then it returns true. (which is only the case if the address is the same).
In String it compares the literals which are included in the String object,
so it returns true when the content is the same not the object.
Hope that helps
[ August 20, 2003: Message edited by: Oliver Refle ]
 
Barry Gaunt
Ranch Hand
Posts: 7729
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roger, would you please put your Java code fragments between code markers thus:

It makes it so much easier to read.
You can find a "CODE" button just below the text entry box.
Thanks
-Barry
[ August 20, 2003: Message edited by: Barry Gaunt ]
 
Jeff Bosch
Ranch Hand
Posts: 805
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd like to expand on Oliver's explanation.
The sample code creates two StringBuffer objects, sb1 and sb2. Because these are different objects, they will have different addresses. When running sb1.equals(sb2) -- or when comparing any two StringBuffer objects, you would always get the result == false for the reasons Oliver stated.
For a String object, the String pool changes things a little:

In this case, both conditions are true because the JVM creates the "String" in the String pool only once, so we have two references (s1, s2) referencing one String object. Using "new" here would change the result, but that's another topic.
Hope that helps!
Regards,
Jeff
 
k Oyedeji
Ranch Hand
Posts: 96
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi
The replies given have been very educational. I was not aware there is a string pool. HOw does this work? Are all strings added to the pool automatically?

Thanks
 
Jeff Bosch
Ranch Hand
Posts: 805
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The JVM keeps a String constant pool as a way to economize memory usage. If two String objects have the same contents (value), then the JVM will only have to create one object. This saves memory, as the following example illustrates.
Two ways to create String objects are:

Line 1 creates one String object in the JVM String constant pool and assigns the reference to that object to s1.
Line 2 creates two String objects, one in the String constant pool and one in normal heap memory, and assigns the reference to the object in normal heap memory to s2.
Line 3 creates no new String objects because the JVM will check the String constant pool, find a String object that matches, and assign its reference to s3. In other words, the test (s1 == s3) will return true.
This raises the issue of why String objects are immutable: You now have two variables, s1 and s3, both expecting to refer to a String object with the value "First String". Now, if some code comes along and changes the (hypothetically changeable) String referenced by s3, that also would change the String referenced by s1. Code that uses s1 just might complain about that.
The solution is that when code purports to modify a String, it really creates a new String object and reassigns the reference to the new object. So, s3 += " Team"; will now point to a new String object in the String constant pool that has the value "First String Team", and the test (s3 == s1) will no longer return true.
 
Nischal Tanna
Ranch Hand
Posts: 182
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A simple theoretical explanation is..
The super class of all classes i.e., the Object class has a method with signature
boolean equals(Object o)
these method compares the references of the 2 objects ie., their addressed and not their values .
Now All the other classes have to override these method.
take for example..String class.
Now considering StringBuffer class ,these class has not overridden the equals method of the Object class and hence it just compares the refernces of the 2 objects and not their values.i Hope this works out.
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic