• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Why are same stringbuffers not equal?

 
Chandra Bairi
Ranch Hand
Posts: 152
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
String s = "String";
StringBuffer sb1 = new StringBuffer(s);
StringBuffer sb2 = new StringBuffer(s);
if(sb1==sb2)
{
System.out.println("hi");
}
There is a lot of confusion as far as the string buffers and the strings are concerned. they exhibit lot of peculiar behaviour. can someone explain as to when the two strings will be equal and when tto stringbuffer objects will be equal. I mean under what conditions sometimes doing the same operations on two different set of strings are producing contradicting results. for ex: the code
public class ADirtyOne
{
public static void main(String[] a) {
if("String".replace('g','G') == "String".replace('g','G'))
System.out.println("Equal");
else
System.out.println("Not Equal");
}
}
produces the value "Not Equal" but the same code when changed to the following produces the value

public class ADirtyOne05
{
public static void main(String[] a) {
if("String".replace('g','g') == "String".replace('g','g'))
System.out.println("Equal");
else
System.out.println("Not Equal");
}
}
"Equal"
I am unable to sort out when there is a distinction and when the strings are equal. are there any articles or examples which can make the concepts of strings and stringbuffers clear. thanks for any help.
 
Donald R. Cossitt
buckaroo
Ranch Hand
Posts: 401
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

returns "True"

returns "True" as well.

returns 13288040 & 27355241
Which demonstrates that sb1 and sb2 are references to two different objects therefore, not equal.
HTH
[ October 20, 2003: Message edited by: Donald R. Cossitt ]
 
fred rosenberger
lowercase baba
Bartender
Pie
Posts: 12015
24
Chrome Java Linux
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
here's my guess...
in the first example. when you have the
String.replace('g','G')
the JVM must do the substitution. it has to temporarily store the modified version of the string somewhere (remember the string itself is never changed). then, it has to do ANOTHER substitition, so it has to store THAT modified version of the string somewhere.
so, we now basically have two pointers to two different memory location. hence, the are not equal.
why the second version does give you a true... maybe the compiler is smart enough to optimize away these since this substitition doesn't do anything???
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24204
34
Chrome Eclipse IDE Mac OS X
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You've asked this same question several times now, and personally I thought I did a good job explaining it here.
Summary:
1) The "==" opertor returns true if, and only if, you're comparing the same physical object to itself. It is never overloaded to mean anything else, as it can be in C++.
2) The "equals" method is intended to be implemented such that it returns true for two "equivalent" but distinct objects. In Java, you override "equals", not "operator==".
3) All instances of a specific String literal -- i.e., "String" -- in a given JVM always refer to the same physical object.
4) On the other hand, there's no such guarantee for Strings created at runtime: if I call String.replace('g', 'G') twice, the two Strings that are returned will be two physically separate objects with identical contents.
I'm not sure why, given these facts, you're still having trouble understanding the code examples above. They imply that, quite reasonably, the replace() method is smart enough to just return the same String object you call it on if its two arguments are identical, but otherwise it must create a new String object at runtime.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic