strange result for String

J

James

Here I face a strange thing when doing with String

str1,str2 is String and str1 and str2 is same string data (example like
str1="abc" and str2 is parameter in 1 method and assume it get "abc" string)
from this expression
if (str1==str2)
I get the "false" for result but when I use str1.equalsIgnoreCase(str2)
the result is true

anyone know why?

Here another one

** str3 is function parameter and assume it get "abc" in

String test=new String("abc");
String t1=new String(str3);
System.out.println((t1==test));
The result is false

so I want to ask, when put str1==str2 ,is that compare the value inside
string or it compare these 2 whether is same object?
 
V

Vincent Cantin

Here I face a strange thing when doing with String
str1,str2 is String and str1 and str2 is same string data (example like
str1="abc" and str2 is parameter in 1 method and assume it get "abc" string)
from this expression
if (str1==str2)
I get the "false" for result but when I use str1.equalsIgnoreCase(str2)
the result is true

anyone know why?

because "(str1==str2)" test only the adresses of the 2 objects in memory and
not the content.
For a normal use of the comparison, use "str1.equals(str2)"

Here another one

** str3 is function parameter and assume it get "abc" in

String test=new String("abc");
String t1=new String(str3);
System.out.println((t1==test));
The result is false

so I want to ask, when put str1==str2 ,is that compare the value inside
string or it compare these 2 whether is same object?

"new String("abc")" create a new object which is "=="-different that "abc".


Vincent
 
M

Michael Borgwardt

James said:
so I want to ask, when put str1==str2 ,is that compare the value inside
string or it compare these 2 whether is same object?

The latter, obviously. Note that compile-time constants (i.e. literals
and expressions composed only of them) are handled in such a way that
two constants with the same content will become the same object.
You can make use of the same mechanism with the String.intern()
method: references returned by this method will refer to the same object
if the objects the method was called on had the same content.
 
O

Oliver Klein

James said:
Here I face a strange thing when doing with String

str1,str2 is String and str1 and str2 is same string data (example like
str1="abc" and str2 is parameter in 1 method and assume it get "abc" string)
from this expression
if (str1==str2)
I get the "false" for result but when I use str1.equalsIgnoreCase(str2)
the result is true

anyone know why?

Here another one

** str3 is function parameter and assume it get "abc" in

String test=new String("abc");
String t1=new String(str3);
System.out.println((t1==test));
The result is false

so I want to ask, when put str1==str2 ,is that compare the value inside
string or it compare these 2 whether is same object?

You can't compare strings that way. The String class is no primitive.
Have a look @ JavaDoc for String.intern() method ...
 
A

Anony!

You can't compare strings that way. The String class is no primitive.
Have a look @ JavaDoc for String.intern() method ...

I assume intern() method is short for internal?

I assume

str1.intern() == str2.intern()

is the same as

st1.equals(str2)

I have never used the intern() method. I dont see the real use of it?


AAa
 
M

Michael Borgwardt

Anony! said:
I assume intern() method is short for internal?
Probably.

I assume

str1.intern() == str2.intern()

is the same as

st1.equals(str2)

That is exactly how it's defined in the method's API documentation.
I have never used the intern() method. I dont see the real use of it?

It allows you to use the much faster == comparison on String objects
"treated" with it (and constants). If you have strings that you
have to compare a lot (many times for each String) then using intern()
could result in a HUGE performance improvement, especially if the
Strings are long, have the same lenght and often start out the same
and differ only in the end (because then equals() takes a lot of time).
 
M

Michael Borgwardt

VisionSet said:
If there is ever a reason to do new String() then you should consider using
intern().

I don't see any connection at all there.

Use intern() when you want to be able to compare Strings with ==,
that's all.
 
V

VisionSet

Anony! said:
I assume intern() method is short for internal?

I assume

str1.intern() == str2.intern()

is the same as

st1.equals(str2)

I have never used the intern() method. I dont see the real use of it?

A String is a simple object much used and abused.
The compiler takes your

String s = "Hi";

and really does

String s = new String("Hi").intern();

So it is being done for you.

This adds your String to a Set maintained by the VM. Ensuring that no
duplicates are created. This is where internal comes from.

The point is that a String is immutable so there is no point having
duplicates.

I can't really think of a good example for explicitly calling intern.

Perhaps when Strings are deserialised duplicates are created so you could
use it then, not sure though.

If there is ever a reason to do new String() then you should consider using
intern().
 
V

VisionSet

Michael Borgwardt said:
I don't see any connection at all there.

I'm just saying that if you have reason to (example please...) use new
String() then intern is not implicitly called and you should be aware of
that.
Maybe the only reason to call new String() is that you do want duplicate
strings, in which case you are aware of that. But maybe there is some other
reason I'm not aware of.
Use intern() when you want to be able to compare Strings with ==,
that's all.

Yes that makes sense, I'll be alert to that now.
 
J

John C. Bollinger

Michael said:
That is exactly how it's defined in the method's API documentation.



It allows you to use the much faster == comparison on String objects
"treated" with it (and constants). If you have strings that you
have to compare a lot (many times for each String) then using intern()
could result in a HUGE performance improvement, especially if the
Strings are long, have the same lenght and often start out the same
and differ only in the end (because then equals() takes a lot of time).

However, remember to observe moderation in everything. If you intern a
String then one copy sticks in the JVM for the entire remainder of that
JVM's lifetime. If you intern many large strings then you can eat up
quite a bit of the available memory and thereby cause yourself problems.

If you find yourself wanting to compare large Strings with equals() then
it probably makes more sense to redesign the program. Indeed, if you
find yourself even _creating_ very large Strings (for some fuzzy
definition of "very large") then you may want to consider whether there
is a better way of accomplishing your goal.


John Bollinger
(e-mail address removed)
 
A

Anony!

Use intern() when you want to be able to compare Strings with ==,
Yes that makes sense, I'll be alert to that now.

But you can us the equals() method to do the same thing. The only reason to
use intern() that has been suggested is for its performance advantage when
handling large strings.


AaA
 
M

Michael Borgwardt

Anony! said:
But you can us the equals() method to do the same thing. The only reason to
use intern() that has been suggested is for its performance advantage when
handling large strings.

No, the main criterium for whether it is an advantage is whetzher you'll be
doing MANY comparisons of the same strings. intern() almost certainly
takes considerably more time than equals(), but you have to do it only once
for each String and can use the lightning-fast == thereafter.

It gains you more for longer strings because equals() takes more time then
(unless the length differs or the Strings differ right at the front), so
the difference between equals() and == is larger.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,997
Messages
2,570,241
Members
46,831
Latest member
RusselWill

Latest Threads

Top