File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Beginning Java and the fly likes Why are same stringbuffers  not equal? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Why are same stringbuffers  not equal?" Watch "Why are same stringbuffers  not equal?" New topic

Why are same stringbuffers not equal?

Chandra Bairi
Ranch Hand

Joined: Sep 12, 2003
Posts: 152
String s = "String";
StringBuffer sb1 = new StringBuffer(s);
StringBuffer sb2 = new StringBuffer(s);
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("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("Not 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
Ranch Hand

Joined: Jan 31, 2003
Posts: 401

returns "True"

returns "True" as well.

returns 13288040 & 27355241
Which demonstrates that sb1 and sb2 are references to two different objects therefore, not equal.
[ October 20, 2003: Message edited by: Donald R. Cossitt ]

fred rosenberger
lowercase baba

Joined: Oct 02, 2003
Posts: 11955

here's my guess...
in the first example. when you have the
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???

There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Ernest Friedman-Hill
author and iconoclast

Joined: Jul 08, 2003
Posts: 24199

You've asked this same question several times now, and personally I thought I did a good job explaining it here.
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.

[Jess in Action][AskingGoodQuestions]
I agree. Here's the link:
subject: Why are same stringbuffers not equal?
It's not a secret anymore!