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


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "String" Watch "String" New topic
Author

String

anushree ari
Ranch Hand

Joined: Sep 30, 2002
Posts: 98
hi guys,
i came through this question in j@whiz, i couldn't undersand the result,plz anybody can explain in detail?
public class string{
public static void main(String args[])
{
String s1=new String("amit");
System.out.println(s1.replace('m','r'));
System.out.println(s1);
String s3="arit";
String s4="arit";
String s2=s1.replace('m','r');
System.out.println(s2==s3);
System.out.println(s3==s4);
}
}
ans is,
arit
amit
false
true
i want to know s2==s3 results false how?


anushree
Dan Chisholm
Ranch Hand

Joined: Jul 02, 2002
Posts: 1865
The equals operator, ==, compares the references for equality. The s3 and s4 references both refer to the same instance of a String constant so s3 and s4 contain the same reference value and the equality operator returns the boolean value "true".
The s2 reference refers to a new instance of a String object that is not the same instance as the String constant referenced by s3 and s4 so the equals operator, ==, returns false.


Dan Chisholm<br />SCJP 1.4<br /> <br /><a href="http://www.danchisholm.net/" target="_blank" rel="nofollow">Try my mock exam.</a>
Arpana Rai
Ranch Hand

Joined: Nov 12, 2002
Posts: 93
Originally posted by Dan Chisholm:
The equals operator, ==, compares the references for equality. The s3 and s4 references both refer to the same instance of a String constant so s3 and s4 contain the same reference value and the equality operator returns the boolean value "true".
The s2 reference refers to a new instance of a String object that is not the same instance as the String constant referenced by s3 and s4 so the equals operator, ==, returns false.


But Dan,the replace method at line 2 should not return new string object as "arit" is already present in string pool(line 1). so line 3 must result 2 true .
regds
Arpana


SCJP1.4(91%)
Dan Chisholm
Ranch Hand

Joined: Jul 02, 2002
Posts: 1865
Originally posted by Arpana Rai:

But Dan,the replace method at line 2 should not return new string object as "arit" is already present in string pool(line 1). so line 3 must result 2 true .
regds
Arpana

Your thinking is certainly logical but the replace method does not work that way. If the String does indeed contain the char to be replaced then the contents of the String is copied to a char array and then all occurrences of the old character are replaced by the new character. The resulting character array is then passed as an argument to the String constructor to create a new instance of a String.
If you would like the new String reference to refer to a String that already exists in the String constant pool then you must invoke the intern method on the String instance.
Arpana Rai
Ranch Hand

Joined: Nov 12, 2002
Posts: 93
Originally posted by Dan Chisholm:

Your thinking is certainly logical but the replace method does not work that way. If the String does indeed contain the char to be replaced then the contents of the String is copied to a char array and then all occurrences of the old character are replaced by the new character. The resulting character array is then passed as an argument to the String constructor to create a new instance of a String.
If you would like the new String reference to refer to a String that already exists in the String constant pool then you must invoke the intern method on the String instance.

Thanx Dan, but what are other methods of String class which beahave like its replace() method, i,e return different string obeject even when the string literal is present in string pool.
Thanx for your kind help.
regds
Arpana
Dan Chisholm
Ranch Hand

Joined: Jul 02, 2002
Posts: 1865
The String constructor does not check the String constant pool when it creates a new String object. All String methods that return a new instance of a String use the String constructor so none of them check the String constant pool.
Arpana Rai
Ranch Hand

Joined: Nov 12, 2002
Posts: 93
Originally posted by Dan Chisholm:
The String constructor does not check the String constant pool when it creates a new String object. All String methods that return a new instance of a String use the String constructor so none of them check the String constant pool.


In the above code at line 1 s1 is refering to string literal, so it will never be eligible for garbage collection.But Dan, according to what you said, at line 2 s1 is refering to new String object though "java" is already present in String pool.So it may be eligible for garbage collection.
Am i going on right track??
Thanx
regds
Arpana
Dan Chisholm
Ranch Hand

Joined: Jul 02, 2002
Posts: 1865
If, for example, the reference s1 is set to null or if s1 goes out of scope then the object would be eligible for garbage collection.
Ron Newman
Ranch Hand

Joined: Jun 06, 2002
Posts: 1056
I don't think there's any way for a constructor to return a previously created object, even if it wanted to.


Ron Newman - SCJP 1.2 (100%, 7 August 2002)
Ron Newman
Ranch Hand

Joined: Jun 06, 2002
Posts: 1056

Since s is already all-lower-case, s.toLowerCase()
just returns s. s1==s and therefore is not eligible for garbage collection.
[ November 24, 2002: Message edited by: Ron Newman ]
Dan Chisholm
Ranch Hand

Joined: Jul 02, 2002
Posts: 1865
Yes, and other String methods such as trim, toUpperCase, concat and replace behave similarly and toString never creates a new instance of the String object. I really need to take a closer look at some of these questions before posting a careless answer.
Arpana Rai
Ranch Hand

Joined: Nov 12, 2002
Posts: 93
Thanx Dan and Ron,this disscussion has realy made my concept clear and strong on String object
regds
Arpana
anushree ari
Ranch Hand

Joined: Sep 30, 2002
Posts: 98
thx arpana and dan, it's really big help for me,if i wouldn't post this question, i thought my concept is correct, thx for correct me,
Timothy Toe
Ranch Hand

Joined: Oct 19, 2002
Posts: 156
Originally posted by Dan
The String constructor does not check the String constant pool when it creates a new String object. All String methods that return a new instance of a String use the String constructor so none of them check the String constant pool.

Pls correct me if I am wrong :
"The String constructor does not check the String constant pool when it creates a new String object." - correct
"All String methods that return a new instance of a String use the String constructor so none of them check the String constant pool." - wrong. These methods (eg trim, to UpperCase, replace) do check the String pool. If no change to the string that they are working on is required and if their (String methods) result is the same as one of the literal strings in the pool, then they return the reference of the literal string that is in the pool.
david eberhardt
Ranch Hand

Joined: Jul 02, 2002
Posts: 158
It appears that when you call a method that actually manipulates an existing String object, then the result is a new String assigned to the new variable as in:

The opposite is also correct:

final note: in these examples, a copy of the exisitng String was manipulated and assigned to a new String variable - therefore, the pre-exisiting String object was not changed.
here's some code I ran to test the other methods:
anushree ari
Ranch Hand

Joined: Sep 30, 2002
Posts: 98
so david according to code what is your final comments about string and string pool,
thx for such a nice example,
david eberhardt
Ranch Hand

Joined: Jul 02, 2002
Posts: 158
Originally posted by anushree ari:
so david according to code what is your final comments about string and string pool,
thx for such a nice example,

Posting the results of the hashCode() method in my previous examples CAN be misleading - the hashCode() method is directly related to the equals() method so we aren't getting the right info regarding whether or not the objects are the same or different.
So I revised my code and explicitly use == to see if the references are pointing at same object. (see sample below) ....

Conclusions:
1) if you use the syntax String varName = new String("example");
you always get a new, distinct object.
2) if you use the syntax String varName = "example";
the String Pool is checked for existence of exact same String - if it finds one, then a reference to that existing String is returned (no new String was created).
3) if you manipulate any String object ( such as s1 = s.toLowerCase() ) AND this results in a change, then the new reference variable will point to a new, distinct object
-------------------------------------------------
this:
String s1 = "java";
String s2 = "JAVA";
String s3 = s2.toLowerCase()
s3 will be a new String object - s3 == s1 is FALSE
[ December 02, 2002: Message edited by: david eberhardt ]
david eberhardt
Ranch Hand

Joined: Jul 02, 2002
Posts: 158
but this:
String s1 = "java";
String s2 = "java";
String s3 = s2.toLowerCase()
no change to s2 object so s3 == s1 is TRUE
...what happens here is that s2 ended up pointing to same String as s1, because it was already in String Pool.

since calling s2.toLowerCase() did not create anything new, s3 ends up pointing at s2 which is already pointing at s1 SO s3==s1.
I hope I'm not all wet after having spent so much time in the String Pool
:roll:
[ December 02, 2002: Message edited by: david eberhardt ]
anushree ari
Ranch Hand

Joined: Sep 30, 2002
Posts: 98
thx david
Salim Mohamed
Ranch Hand

Joined: Sep 19, 2002
Posts: 55
How StringBuffer is different from the String ?
In the following program the output is "unequal equal"
public class Test004 extends Object
{
public static void main(String[] args)
{
StringBuffer sb1 = new StringBuffer("hello");
StringBuffer sb2 = new StringBuffer("hello");
String s1 = new String(sb1);
String s2 = new String(sb2);
if (sb1.equals(sb2)) {
System.out.print("equal");
} else {
System.out.print("unequal");
}
if (s1.equals(s2)) {
System.out.println(" equal");
} else {
System.out.println(" unequal");
}
}
}
How ?
anushree ari
Ranch Hand

Joined: Sep 30, 2002
Posts: 98
string buffer doesn't override the equals method,so it returns false,NOTE: it doesn't give error.
the second one is always equal
anushree ari
Ranch Hand

Joined: Sep 30, 2002
Posts: 98
second one is creation of string its not stringbuffer, (string s2).
Abu Yoosuf
Ranch Hand

Joined: Nov 14, 2002
Posts: 33
java.lang.String overrides the equals() of java.lang.Object.
StringBuffer inherits its parent's (i.e. java.lang.Object) equals().
The equals() for java.lang.String, returns true if the sequence of characters in both strings are same. When you create a new String from a StringBuffer (i.e. new String(StringBuffer sb)) it calls getValue() on sb which returns a char[]. The following code snippet shows what maybe happening:


sb1 and sb2 are referencing 2 different new StringBuffer objects. The equals() method for java.lang.Object implementation, basically checks for whether the given obj reference is the same as the one we are testing against. So, sb1.equals(sb2) returns false.


The equals() methods in both cases do what they have been asked to do by the implementation code.
[ December 02, 2002: Message edited by: Abu Yoosuf ]
Abu Yoosuf
Ranch Hand

Joined: Nov 14, 2002
Posts: 33
Also check out the equals() methods of wrapper classes for primitive types.
Integer.equals()
Double.equals()
Long.equals() ...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: String