• Post Reply Bookmark Topic Watch Topic
  • New Topic

Question about toString() method  RSS feed

 
Vijay Tyagi
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator




Above code results in Equal

"String".toString() will create a String "String",how is it that both "String"s are the same ?



While in below code, the output is "Not Equal"






please answer

thanks


 
Jesus Angeles
Ranch Hand
Posts: 2070
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
== compares the reference to the objects, by which the 2nd is false because of how Strings are handled in memory.

If you really want both to return true, you need to look at the equals*() methods.
 
Vijay Tyagi
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jesus Angeles wrote:== compares the reference to the objects, by which the 2nd is false because of how Strings are handled in memory.

If you really want both to return true, you need to look at the equals*() methods.




But why does the first one return Equal

"String".toString() and "String" are not the same,though their content is same
 
Jesus Angeles
Ranch Hand
Posts: 2070
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
http://www.coderanch.com/t/381045/java/java/String-Memory-Allocation mentions about string allocations.

There is a String pool in the jvm. String is immutable that is why this is possible. New strings of the same content can point to the same string in the string pool.

Equals*() compares the 'content'. == compares the reference to the string (which can be in the string pool, shared by many).

String.toString() returned the same reference to "String", that is why it is 'true'. They point to the same string in the pool.

String.trim() returned a reference to a String different for the reference of "String".

 
Vijay Tyagi
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jesus Angeles wrote:http://www.coderanch.com/t/381045/java/java/String-Memory-Allocation mentions about string allocations.

There is a String pool in the jvm. String is immutable that is why this is possible. New strings of the same content can point to the same string in the string pool.

Equals*() compares the 'content'. == compares the reference to the string (which can be in the string pool, shared by many).

String.toString() returned the same reference to "String", that is why it is 'true'. They point to the same string in the pool.

String.trim() returned a reference to a String different for the reference of "String".



"String".toString() points to same "String" in String constant pool ,going by that logic,
" String ".trim() should also point to the same "String" in string constant pool , and return Equal
 
Jesus Angeles
Ranch Hand
Posts: 2070
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think http://www.coderanch.com/t/572211/java/java/String-pool#2602547 answers that.

The "String" is a literal, and if not yet in the pool, is created in the pool. Lets say, object reference A.

" String ".trim() creates a "String" in the heap. It will be a new reference, not same as A.

 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Vijay Tyagi wrote:"String".toString() and "String" are not the same,though their content is same

If you think about it, that statement can't possibly be true, because you've already proved that they are the same.

"String".toString() points to same "String" in String constant pool ,going by that logic,
" String ".trim() should also point to the same "String" in string constant pool , and return Equal

I don't know how you arrived at that conclusion.

" String " and "String" are plainly NOT the same, so why would you think that " String ".trim() would somehow return the same object as "String"?
I suppose in theory it could, if it used String.intern() internally; but that's an awfully big assumption to make.

The pool is mostly for rationalizing String literals. You shouldn't make any other assumptions about when it's used.

And furthermore, you should never use '==' to compare reference types - or at least not until you're a lot further down the road. Always, always, always use equals().

Winston
 
Campbell Ritchie
Marshal
Posts: 56578
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Vijay Tyagi wrote: . . . "String".toString() will create a String . . .
Where did you get that from? Read the API documentation and you find the real answer.
 
Vijay Tyagi
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:
Vijay Tyagi wrote:"String".toString() and "String" are not the same,though their content is same

If you think about it, that statement can't possibly be true, because you've already proved that they are the same.

"String".toString() points to same "String" in String constant pool ,going by that logic,
" String ".trim() should also point to the same "String" in string constant pool , and return Equal

I don't know how you arrived at that conclusion.

" String " and "String" are plainly NOT the same, so why would you think that " String ".trim() would somehow return the same object as "String"?
I suppose in theory it could, if it used String.intern() internally; but that's an awfully big assumption to make.

The pool is mostly for rationalizing String literals. You shouldn't make any other assumptions about when it's used.

And furthermore, you should never use '==' to compare reference types - or at least not until you're a lot further down the road. Always, always, always use equals().

Winston


thanks for answering, everyone
It's clear now, after a bit of experimenting,now I know why
"String".toString()=="String" returns true
and " String ".trim()=="String" returns false
 
Campbell Ritchie
Marshal
Posts: 56578
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are still mistaken, I am afraid, because you are still using the == operator on reference types.
 
Rajdeep Biswas
Ranch Hand
Posts: 231
1
Eclipse IDE Java Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
" String ".trim() create a "String" literal, places in pool() and creates another on heap outside pool. Which reference is returned if already one literal exists in the pool?
 
Rob Spoor
Sheriff
Posts: 21135
87
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rajdeep Biswas wrote:" String ".trim() create a "String" literal, places in pool() and creates another on heap outside pool. Which reference is returned if already one literal exists in the pool?

" String ".trim() does not create a String literal. " String " is a String literal, but the created "String" is no literal. It will always be a new String object.
If the String to trim needs no trimming (e.g. "String".trim()) it will return the original String. In all other cases a new String object.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rajdeep Biswas wrote:" String ".trim() create a "String" literal, places in pool()...

That's the whole point - IT DOESN'T.

The only way it could would be if trim() was specifically coded like this:and that's an awfully big assumption to make.

And you must remember the old chestnut about assumptions:
ASSUME makes an ASS out of 'U' and 'ME'.



Winston
 
Rajdeep Biswas
Ranch Hand
Posts: 231
1
Eclipse IDE Java Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So

hello goes in the pool

what happens? s2 holds what reference?

what happens and s3 holds what reference?
 
Rob Spoor
Sheriff
Posts: 21135
87
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rajdeep Biswas wrote:So

hello goes in the pool

Correct.

what happens? s2 holds what reference?

This creates a "hello" String literal that goes into the String pool. It then creates a new String, not in the String pool, that is an exact copy. Likewise for s3.
Because Strings are immutable there is almost never a need to use this String constructor. It just creates a new String that is an exact copy of another String. Unless that's exactly what you want you should avoid it.
 
Rajdeep Biswas
Ranch Hand
Posts: 231
1
Eclipse IDE Java Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But s2 holds the pool stuff's reference or the new object reference?
 
dennis deems
Ranch Hand
Posts: 808
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rajdeep Biswas wrote:But s2 holds the pool stuff's reference or the new object reference?

A reference to a new object. Any time you use the new keyword to make a String, a new object is created, even if the literal already exists in the pool.
 
Rajdeep Biswas
Ranch Hand
Posts: 231
1
Eclipse IDE Java Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So When I do as:


hello is placed in the pool and also a copy is created as part of a new object, s1 holds reference of which.


ensures that s2 points to the hello already in the pool.

And then when I do:


Then hello is already in the pool and s3 is the reference to the new object storing hello.

Are my assumptions valid?
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rajdeep Biswas wrote:And then when I do:Then hello is already in the pool and s3 is the reference to the new object storing hello.

Are my assumptions valid?

As I've tried to explain, it depends entirely on exactly how the trim() method works, and for that you'd have to read the source code (which, of course, would only give you one implementation). What you absolutely should NOT do is assume that it returns a reference to a String in the pool.

And anyway, where does all this speculation get you? You should never compare Strings with '=='...Ever.

Winston
 
Campbell Ritchie
Marshal
Posts: 56578
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You want look in the documentation, where it tells you all you need to know. Look what it says about new String objects. Note what it doesn’t say about interning anything, or putting anything in the String pool. You can try a test
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!