aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes About String Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "About String " Watch "About String " New topic
Author

About String

Raj Kumar
Ranch Hand

Joined: Sep 19, 2005
Posts: 65
Hi,

Code 1:

if("String".replace('T','t') == "String")
System.out.println("Equal");
else
System.out.println("Not Equal");

Output : Equal
-------------------------------------------------------

Code 2:
if("String".trim() == "String".trim())
System.out.println("Equal");
else
System.out.println("Not Equal");

Output : Equal

----------------------------------------------------------

Code 3 :
if("String".replace('g','G') == "String".replace('g','G'))
System.out.println("Equal");
else
System.out.println("Not Equal");

Output : NotEqual


----------------------------------------------------------


Pls. explain 3 prints "not equal" and the other 2 equal
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

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.

Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Raj Kumar
Ranch Hand

Joined: Sep 19, 2005
Posts: 65
Sorry Mark,
i can't understand. the first returns "STring" it is still in string pool but he thrid ho can it get to the Heap.

some more explanation will help me .
Phil Kurian
Ranch Hand

Joined: Feb 26, 2006
Posts: 35
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.


SCJP (1.4)
Changchun Wang
Ranch Hand

Joined: Feb 15, 2006
Posts: 83
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 !
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18101
    
  39

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.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Raj Kumar
Ranch Hand

Joined: Sep 19, 2005
Posts: 65


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..


if( "STRING".toUpperCase() == "STRING")
System.out.println("Equal");
else
System.out.println("Not Equal");

working perfectly

thanks a lot
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[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
Thanks Jim,

Always good to get a better understanding of the rules
Sandeep Vaid
Ranch Hand

Joined: Feb 27, 2006
Posts: 390
I think what Phil is saying is correct. Coonsider the codes below :

1. System.out.println("x".replace('x', 'y') == "y");

Now since the actual replacement is done , they are different
Hance false.

2. System.out.println("x".replace('x', 'x') == "x");

Now since the actual replacement is NOT done , they are same
Hence true.
[ February 28, 2006: Message edited by: Sandeeep Vaid ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: About String
 
Similar Threads
String Methods
String
Java Strings
String == (Abhilash mock)
Different behaviour with string objects