• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Why are same stringbuffers not equal?

 
Ranch Hand
Posts: 152
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
buckaroo
Posts: 401
Postgres Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ]
 
lowercase baba
Posts: 13089
67
Chrome Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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???
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Oh, sure, you could do that. Or you could eat some pie. While reading this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic