Simple put. The first two have the String "String" in the String pool. In both of those cases the return value for the method invocation is still "String" so it uses the one and only one object in the String pool. Therefore, they are "=="
Now in the third example. The return value is "StrinG", which is not in the String pool. So therefore the return value for each method call returns a new seperate object on the heap. And therefore are different and not "==". Now if you used the equals() method on them then they would return equal.
The first method doesn't return "STring", but it returns "String" (given the order of the chars in the replace method).
The string "String" is interned (i.e put into memory pool) as you have implicitly created an String object called with the value "String". By running the first replace method, no modification is made to the string, so no new String is created. Both sides of the boolean Operator (==) still point to the same interned string (i.e. same address in memory).
The third method however has to creates new Strings. Both sides of the boolean operator (==) will create new strings and consequently assign them different addresses (even though the content is the same). As the addresses are different. the == comparison returns false, as == when refering to Objects is comparing the address reference.
I could be wrong on this, but whenever you run replace on a string, and a modified string results, a new string is created (even if it has the same character sequence as a string in the pool) and consequently has a different address. If however a resulting string from a string function (eg. replace, trim) is the same as the original string, then no new string is created and the resulting string just points back to the original interned string.
For example the following code will print false:
public class Stringy {
public static void main(String[] args) { String s = "StrinG"; String s2 = "String"; String s3 = s2.replace('g', 'G'); System.out.println(s3==s);
} }
This is despite the fact that s already interns the string "StrinG". the replace function will implicitly create a new string in memory.
hi Raj Kumar pay attenton to if("String".replace('T','t') == "String")
but I have a question about that too!
The return value is "StrinG", which is not in the String pool So therefore the return value for each method call returns a new seperate object on the heap
why each method call returns a new seperate object on the heap other than in the string pool? Mark Spritzler, could you explain it thanks in advance !
why each method call returns a new seperate object on the heap other than in the string pool? Mark Spritzler, could you explain it thanks in advance !
The string pool is for constants -- created by the compiler. All new string objects created are on the heap. The reason the replace() method is returning an object in the string pool, is because the method calculated that the result is the same as the original object, and return the original object.
I could be wrong on this, but whenever you run replace on a string, and a modified string results, a new string is created (even if it has the same character sequence as a string in the pool) and consequently has a different address. If however a resulting string from a string function (eg. replace, trim) is the same as the original string, then no new string is created and the resulting string just points back to the original interned string.
Thanks Phil Kurian, this is really working chekcthis even too..
[Phil]: If however a resulting string from a string function (eg. replace, trim) is the same as the original string, then no new string is created
That's often true, but not always. For example:
It's hard to say exactly when a method will return a new string, and when it won't. For this reason, the exam authors have intentionally avoided questions that depend on this issue.
For the exam, you will never need to worry about whether a library method returns a new string or an old one. And you will also never need to know anything at all about the String pool.
In the real world, you should almost always avoid this issue entirely by using equals() rather than == to compare strings. Yes, you can write programs to use == to see what happens, but sometimes this leads to weird and confusing results, which really don't matter in most cases if you just use equals().
"I'm not back." - Bill Harding, Twister
Phil Kurian
Ranch Hand
Joined: Feb 26, 2006
Posts: 35
posted
0
Thanks Jim,
Always good to get a better understanding of the rules
0
