aspose file tools*
The moose likes Beginning Java and the fly likes Could any one please explain this program Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Could any one please explain this program" Watch "Could any one please explain this program" New topic
Author

Could any one please explain this program

Abdul Aatif
Greenhorn

Joined: Feb 08, 2012
Posts: 23
Could any one please explain this program why i am getting False as output

Thanks in Advance

Byte b = new Byte("10");
if(b.toString() == b.toString()){
System.out.println("True");
}else{
System.out.println("False");
}
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 10916
    
  12

because == tests to see if the two references are pointing to the same object. each call of toString creates a new String in memory, so the references are NOT equal.

almost without exception, you NEVER want to use == to compare object - only primitives.

You want to use the equals() method.


There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Enkita mody
Ranch Hand

Joined: Aug 06, 2012
Posts: 333

fred rosenberger wrote:because == tests to see if the two references are pointing to the same object. each call of toString creates a new String in memory, so the references are NOT equal.

almost without exception, you NEVER want to use == to compare object - only primitives.

You want to use the equals() method.


But in code there isn't new keyword, so how they're two different objects please elaborate it.


OCA7
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 10916
    
  12

toString creates a String object every time it is called (even when implicitly called via String concatenation)
Nikhil Sagar
Ranch Hand

Joined: Apr 21, 2012
Posts: 216

fred rosenberger wrote:toString creates a String object every time it is called (even when implicitly called via String concatenation)

So toString() create objects in heap ??


OCPJP 6 86%
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 10916
    
  12

Where else would it create them?

To the best of my knowledge, all objects are created in the heap.
Abdul Aatif
Greenhorn

Joined: Feb 08, 2012
Posts: 23
fred rosenberger wrote:toString creates a String object every time it is called (even when implicitly called via String concatenation)


Sir,

But, if i am executing this line i am getting true as output.

System.out.println(b.toString().hashCode() == b.toString().hashCode());

Thanks in Advance
gurpeet singh
Ranch Hand

Joined: Apr 04, 2012
Posts: 923
    
    1

refer http://docs.oracle.com/javase/6/docs/api/java/lang/Byte.html#toString(byte) . it states that it creates new String object for the corresponding Byte object.

and Nikhil objects are always created on Heap and i think you want to say that whether the reference to object is created in String pool. the fact that == returns false meant that there are 2 different objects(but with same value) created on heap . since they are 2 different objects so == returns false.
there will be total of 3 String objects with value 10. one will have a reference from String memory pool ( the one in Byte b = new Byte("10") whereas others will be created using new operator so they will be seperate objects


OCPJP 6(100 %) OCEWCD 6(91 %) OCPJBCD(93%)
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

fred rosenberger wrote:Where else would it create them?

To the best of my knowledge, all objects are created in the heap.


Up through Java 6, all objects go on the heap. There was talk with Java 7 of allowing objects to be created on the stack if escape analysis could prove they wouldn't live beyond the method call, but I don't know what the final outcome was. It's definitely not a requirement to do so.

It may be that JVMs are allowed to do so (not sure), but I don't think the standard Oracle JVM does it yet (again, not sure).

However, where the object is created has no bearing on the answer to the OP's question.
gurpeet singh
Ranch Hand

Joined: Apr 04, 2012
Posts: 923
    
    1

Latif Khan wrote:
fred rosenberger wrote:toString creates a String object every time it is called (even when implicitly called via String concatenation)


Sir,

But, if i am executing this line i am getting true as output.

System.out.println(b.toString().hashCode() == b.toString().hashCode());

Thanks in Advance


hashCode method is overidden in String class. also the hashCode contracts say that if 2 objects are equal then their hashcode must be equal but not vice versa. here both String objects are equal (you can check it using equals() method) hence they will have same hashCode.

Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Latif Khan wrote:
fred rosenberger wrote:toString creates a String object every time it is called (even when implicitly called via String concatenation)


Sir,

But, if i am executing this line i am getting true as output.

System.out.println(b.toString().hashCode() == b.toString().hashCode());

Thanks in Advance


This is expected. Objects that are equal by equals() are required to have the same hashCode. Note that hashCode is NOT unique. Two completely different objects--of the same class or different classes--can have the same hashCode. If you think about it for a minute it should be obvious that this is the case. For simple proof, consider that there are 2^32 possible hashCode values, but 2^64 possible Long objects. The pigeon-hole principle tells us that they cannot be unique.

HashCode is also NOT the same as "the object's address."
Nikhil Sagar
Ranch Hand

Joined: Apr 21, 2012
Posts: 216

And i thought, one can create String objects on heap using new keyword only.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Nikhil Sagar wrote:And i thought, one can create String objects on heap using new keyword only.


Even if this were true, if you think about it for a minute it should be obvious that we can also do it by calling another method that in turn uses new, rather than having the new directly in our code.
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 10916
    
  12

Nikhil Sagar wrote:And i thought, one can create String objects on heap using new keyword only.

you realize that the toString() method may call "new String" in it somewhere?

Just because you are not explicitly calling it doesn't mean it is not being called.
Nikhil Sagar
Ranch Hand

Joined: Apr 21, 2012
Posts: 216

Jeff Verdegan wrote:
Nikhil Sagar wrote:And i thought, one can create String objects on heap using new keyword only.


Even if this were true, if you think about it for a minute it should be obvious that we can also do it by calling another method that in turn uses new, rather than having the new directly in our code.

Okay Okay....
and

it will create String Object in pool , Correct ??
gurpeet singh
Ranch Hand

Joined: Apr 04, 2012
Posts: 923
    
    1

Hello Nikhil.

objects are always created on heap. when you do String str ="hello world"; the object is created on heap but the reference is put on String constant pool . we normally say that object has been created in string constant pool which has led to your confusion.
regards
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Nikhil Sagar wrote:[
and

it will create String Object in pool , Correct ??


Yes.

A String constant entry goes into the .class file. When the class is loaded, if an equal String object is not already present in the JVM's constant pool, then a new String object is created in the constant pool by the JVM. It may call some Java code that uses the new operator, or it may just create it directly.
Nikhil Sagar
Ranch Hand

Joined: Apr 21, 2012
Posts: 216

gurpeet singh wrote:Hello Nikhil.

objects are always created on heap. when you do String str ="hello world"; the object is created on heap but the reference is put on String constant pool . we normally say that object has been created in string constant pool which has led to your confusion.
regards

Uff...
Damn Shortcuts....
Well thanks Gurpreet for clearing a very bad Confusion.
Thanks a lot.
and thanks to jeff and fred too.have a look here.
http://www.coderanch.com/t/550614/java/java/many-objects-will-created-string
may be you guys want to correct them too..
Nikhil Sagar
Ranch Hand

Joined: Apr 21, 2012
Posts: 216

then a new String object is created in the constant pool by the JVM


Now i am again confused.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

gurpeet singh wrote:Hello Nikhil.

objects are always created on heap. when you do String str ="hello world"; the object is created on heap but the reference is put on String constant pool . we normally say that object has been created in string constant pool which has led to your confusion.
regards


Executing that line doesn't create the String object. The String object is created when the class is loaded (if there wasn't already an equivalent one in the constant pool), and it is stored in the constant pool, which is part of the heap. Executing that line merely assigns the value of the reference to the constant pool object to the str variable.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Nikhil Sagar wrote:
then a new String object is created in the constant pool by the JVM


Now i am again confused.


I'll be happy to try to clear up your confusion if you elaborate.
gurpeet singh
Ranch Hand

Joined: Apr 04, 2012
Posts: 923
    
    1

Jeff Verdegan wrote:
gurpeet singh wrote:Hello Nikhil.

objects are always created on heap. when you do String str ="hello world"; the object is created on heap but the reference is put on String constant pool . we normally say that object has been created in string constant pool which has led to your confusion.
regards


Executing that line doesn't create the String object. The String object is created when the class is loaded (if there wasn't already an equivalent one in the constant pool), and it is stored in the constant pool, which is part of the heap. Executing that line merely assigns the value of the reference to the constant pool object to the str variable.


i don't think so String pool is a part of heap. Please refer this link http://www.javaranch.com/journal/200409/ScjpTipLine-StringsLiterally.html which says otherwise and which clearly states that objects are created in heap and String constant pool stores references to it.
Nikhil Sagar
Ranch Hand

Joined: Apr 21, 2012
Posts: 216

Jeff, tell me one thing constant pool is a special part of heap memory ??
if yes then,
String str="TEST";
this String object will go into the pool ??
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

gurpeet singh wrote:
Jeff Verdegan wrote:
gurpeet singh wrote:Hello Nikhil.

objects are always created on heap. when you do String str ="hello world"; the object is created on heap but the reference is put on String constant pool . we normally say that object has been created in string constant pool which has led to your confusion.
regards


Executing that line doesn't create the String object. The String object is created when the class is loaded (if there wasn't already an equivalent one in the constant pool), and it is stored in the constant pool, which is part of the heap. Executing that line merely assigns the value of the reference to the constant pool object to the str variable.


i don't think so String pool is a part of heap. Please refer this link http://www.javaranch.com/journal/200409/ScjpTipLine-StringsLiterally.html which says otherwise and which clearly states that objects are created in heap and String constant pool stores references to it.


JVM spec says otherwise:

http://docs.oracle.com/javase/specs/jvms/se5.0/html/Overview.doc.html#22972 says "Each runtime constant pool is allocated from the Java virtual machine's method area (ยง3.5.4)", and that 3.5.4 section that's referenced (http://docs.oracle.com/javase/specs/jvms/se5.0/html/Overview.doc.html#6656) says, "...the method area is logically part of the heap..."

gurpeet singh
Ranch Hand

Joined: Apr 04, 2012
Posts: 923
    
    1

Nikhil Sagar wrote:Jeff, tell me one thing constant pool is a special part of heap memory ??
if yes then,
String str="TEST";
this String object will go into the pool ??

please refer the link i gave above by Corey mcgone. it will clear all your doubts
Nikhil Sagar
Ranch Hand

Joined: Apr 21, 2012
Posts: 216

gurpeet singh wrote:
Nikhil Sagar wrote:Jeff, tell me one thing constant pool is a special part of heap memory ??
if yes then,
String str="TEST";
this String object will go into the pool ??

please refer the link i gave above by Corey mcgone. it will clear all your doubts


I am on it dude. Thanks for the link.
gurpeet singh
Ranch Hand

Joined: Apr 04, 2012
Posts: 923
    
    1

So Jeff that link given on javaranch must be edited and corrected otherwise many people will be confused. what do you think ? or better somebody from you guys write a complete new tutorial/article pertaining string constant pool since this thing causes confusion for every newbie and lots of questions are asked. if we have one article it would be good to redirect the person to that definite article
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Nikhil Sagar wrote:Jeff, tell me one thing constant pool is a special part of heap memory ??


It is a special area of memory that the JVM spec says is "logically part of the heap." These details are not something we need to know to write Java programs though.

if yes then,
String str="TEST";
this String object will go into the pool ??


Yes.

When the class is loaded (initialized, actually, but for most purposes we can consider it the same thing), before that line is executed, if the constant pool does not contain an equal() String, then "TEST" is created in the constant pool.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

gurpeet singh wrote:So Jeff that link given on javaranch must be edited and corrected otherwise many people will be confused. what do you think ?


There are a lot of wrong answers on this site. I try to correct them as I run across them in active threads, but I'm not going to go add to an old, dead thread.

or better somebody from you guys write a complete new tutorial/article pertaining string constant pool


I'm sure there are already plenty of them out there, and there may even be one in this site's FAQ.
gurpeet singh
Ranch Hand

Joined: Apr 04, 2012
Posts: 923
    
    1

Jeff Verdegan wrote:
gurpeet singh wrote:So Jeff that link given on javaranch must be edited and corrected otherwise many people will be confused. what do you think ?


There are a lot of wrong answers on this site. I try to correct them as I run across them in active threads, but I'm not going to go add to an old, dead thread.

or better somebody from you guys write a complete new tutorial/article pertaining string constant pool


I'm sure there are already plenty of them out there, and there may even be one in this site's FAQ.


actually the link i posted earlier is not some thread. it is a full-fledged article given on javaranch posted my Corey Mcgone. since it is an article and this article is given in scjp faq's it ought to be corrected. because thousands of people scjp faq's and they do go through the articles. had it been some thread i wouldn't have posted the link but since it is an official article it should be taken to the notice of moderators. what do you say Jeff ?
Nikhil Sagar
Ranch Hand

Joined: Apr 21, 2012
Posts: 216

fred rosenberger wrote:Where else would it create them?

To the best of my knowledge, all objects are created in the heap.


May be in the pool ?
Nikhil Sagar
Ranch Hand

Joined: Apr 21, 2012
Posts: 216

gurpeet singh wrote:
Jeff Verdegan wrote:
gurpeet singh wrote:So Jeff that link given on javaranch must be edited and corrected otherwise many people will be confused. what do you think ?


There are a lot of wrong answers on this site. I try to correct them as I run across them in active threads, but I'm not going to go add to an old, dead thread.

or better somebody from you guys write a complete new tutorial/article pertaining string constant pool


I'm sure there are already plenty of them out there, and there may even be one in this site's FAQ.


actually the link i posted earlier is not some thread. it is a full-fledged article given on javaranch posted my Corey Mcgone. since it is an article and this article is given in scjp faq's it ought to be corrected. because thousands of people scjp faq's and they do go through the articles. had it been some thread i wouldn't have posted the link but since it is an official article it should be taken to the notice of moderators. what do you say Jeff ?


Actually you have a point man.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

gurpeet singh wrote:
actually the link i posted earlier is not some thread. it is a full-fledged article given on javaranch posted my Corey Mcgone. since it is an article and this article is given in scjp faq's it ought to be corrected. because thousands of people scjp faq's and they do go through the articles. had it been some thread i wouldn't have posted the link but since it is an official article it should be taken to the notice of moderators. what do you say Jeff ?


I guess I clicked the wrong link the first time.

I skimmed that article. The only difference between what it says and what I said is that it seems to consider that only the references are in the constant pool, but that the String objects themselves are not. Reading the relevant parts of the JVM spec, it seems to me that both are in the constant pool (which is, "logically part of the heap"), but I admit it's a bit unclear.

In the end, I don't consider that point important enough to spend any more time on here. Unless you're writing or debugging a JVM, that detail won't matter. What does matter to a Java programmer is that there is a constant pool for Strings, and that certain actions, such as assigning a String literal reference to a variable, result in using an already-existing String, rather than creating a new one.
Nikhil Sagar
Ranch Hand

Joined: Apr 21, 2012
Posts: 216

Jeff Verdegan wrote:
gurpeet singh wrote:
actually the link i posted earlier is not some thread. it is a full-fledged article given on javaranch posted my Corey Mcgone. since it is an article and this article is given in scjp faq's it ought to be corrected. because thousands of people scjp faq's and they do go through the articles. had it been some thread i wouldn't have posted the link but since it is an official article it should be taken to the notice of moderators. what do you say Jeff ?


I guess I clicked the wrong link the first time.

I skimmed that article. The only difference between what it says and what I said is that it seems to consider that only the references are in the constant pool, but that the String objects themselves are not. Reading the relevant parts of the JVM spec, it seems to me that both are in the constant pool (which is, "logically part of the heap"), but I admit it's a bit unclear.

In the end, I don't consider that point important enough to spend any more time on here. Unless you're writing or debugging a JVM, that detail won't matter. What does matter to a Java programmer is that there is a constant pool for Strings, and that certain actions, such as assigning a String literal reference to a variable, result in using an already-existing String, rather than creating a new one.

So, what goes into pool ?
(a.) Object,
(b.) reference variable,
(c.) Both.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Nikhil Sagar wrote:
Jeff Verdegan wrote:
gurpeet singh wrote:
actually the link i posted earlier is not some thread. it is a full-fledged article given on javaranch posted my Corey Mcgone. since it is an article and this article is given in scjp faq's it ought to be corrected. because thousands of people scjp faq's and they do go through the articles. had it been some thread i wouldn't have posted the link but since it is an official article it should be taken to the notice of moderators. what do you say Jeff ?


I guess I clicked the wrong link the first time.

I skimmed that article. The only difference between what it says and what I said is that it seems to consider that only the references are in the constant pool, but that the String objects themselves are not. Reading the relevant parts of the JVM spec, it seems to me that both are in the constant pool (which is, "logically part of the heap"), but I admit it's a bit unclear.

In the end, I don't consider that point important enough to spend any more time on here. Unless you're writing or debugging a JVM, that detail won't matter. What does matter to a Java programmer is that there is a constant pool for Strings, and that certain actions, such as assigning a String literal reference to a variable, result in using an already-existing String, rather than creating a new one.

So, what goes into pool ?
(a.) Object,
(b.) reference variable,
(c.) Both.


As I said: According to the article you linked, only references (not reference variables). According to my interpretation of the relevant sections of the JVM spec, both references and objects. I may be mistaken, or the author of the article may be mistaken.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Could any one please explain this program
 
Similar Threads
toString() Method
String doubt
need explanation on wrapper class
== comparison
object Reference Equality