Stings: how many objects created?

[Prateek Rawal]

Just suppose there are no objects in the String pool:
Let us find out how many objects are created and where?

Case 1:

String s = "abc";    

(1) object is created with value "abc" in the pool and it is referred by s.

[Again suppose there are no objects in the pool]
Case 2:

 
String s = new String("abc");  

(2) objects are created, one in the pool with value "abc" and other in the non-pool memory with value "abc" only.


[Again suppose there are no objects in the pool]
Case 3:

  
String s = "abc" ;               //LINE 01
String s1 =  new String("abc");               //LINE 02 

Now how many objects are created?
I guess(i'm not sure) (2) objects are created,
By LINE 01, a new object is created on pool with value abc,
Now when we write LINE 02, it first search whether there exist a String object with value "abc" in the pool, if it does(as in the present case), it gets the referece of the String object in the pool(here s) and then s is passes to the constructor of String, and a new object is created in the non-pool memory with value "abc"

Am i correct? Correct me if i'm wrong.....

PS: I don't have any idea to confirm my understanding or interpretation, so i find it better to raise it as a topic on javaranch.........

[Abimaran Kugathasan]

Correct. I can sure this....

[Abimaran Kugathasan]

Hi, go through this link, at the bottom of the thread, there is a good example related with String Literal Pool.

[Prateek Rawal]

Excellent help Abhimaram!

And the best part was, wht code you put up asking how many objects were created,

I solved it myself and got the answer as 13,hehe........

Thanks very much.

But only one thing i didn't get, the one with toString()

Look at the following:

 public class A1  {    
   2.     
   3.         public static void main(String argv[]) {      
   4.      StringBuilder s1 =new StringBuilder("apple");//line 1    
   5.      s1.toString();// line 2    
   6.       //line 3        
}
}

Here, one apple literal pool object is create, and a builder object is created with value apple, but what about
s1.toString()...what does it do???
Does it return the apple object on the pool as Ankit told???

[Prateek Rawal]

Also i have two doubts:

1) Is String Pool different from Heap? Or Pool + Non-Pool = Heap?

2) They said, there would be no GC questions on Strings in SCJP, however, can there be questions on Strings about how many objects are created? and how many of them are in pool and how many are in Non-Pool Memory?? it seems quite probable, isn't it?

[Abimaran Kugathasan]

Prateek Rawal wrote:Excellent help Abhimaram!

Somebody changed my name!~

[Abimaran Kugathasan]

Prateek Rawal wrote:Also i have two doubts:

1) Is String Pool different from Heap? Or Pool + Non-Pool = Heap?

String Literal Pool is a part of the heap!

Prateek Rawal wrote:
2) They said, there would be no GC questions on Strings in SCJP, however, can there be questions on Strings about how many objects are created? and how many of them are in pool and how many are in Non-Pool Memory?? it seems quite probable, isn't it?

No.

[Abimaran Kugathasan]

Prateek Rawal wrote:
Here, one apple literal pool object is create, and a builder object is created with value apple, but what about
s1.toString()...what does it do???
Does it return the apple object on the pool as Ankit told???

There is 'space' to StringBuilder object in the String Literal Pool, Check here and here

[Prateek Rawal]

You said

String Literal Pool is a part of the heap!

In the link you gave me earlier, Ankit said:

The toString method of a String object never creates a new String object, neither in the heap nor in the constant pool, it just returns the String object itself i.e. this.

Also in the link you gave me just now i.e. this, in the diagram String pool is shown different from Heap, i guess both are different, just check it out once again......


Hey, those links you gave me, i'm not able to interpret and locate the reference to StringBuilder having a space in the pool, just describe me here.....

Also, Ankit said:

The toString method of a String object never creates a new String object, neither in the heap nor in the constant pool, it just returns the String object itself i.e. this.

Going by this: it can be interpreted that as far as this code is concerned

 public class A1  {      
   2.       
   3.         public static void main(String argv[]) {        
   4.      StringBuilder s1 =new StringBuilder("apple");//line 1      
   5.      s1.toString();// line 2      
   6.       //line 3          
}  }    

it creates apple object on the pool and the StringBuilder object on the non-pool, then s1.toString() doesn't create a new object neither in the heap nor in the pool, but returns the String object associated with the StringBuilder object i.e. in present case- "apple" object.

What say?

[Ankit Garg]

can there be questions on Strings about how many objects are created? and how many of them are in pool and how many are in Non-Pool Memory?? it seems quite probable, isn't it?

You can definitely face a question which asks how many String objects are created, but you won't be asked separately how many will be created in the pool or non-pool.

in the diagram String pool is shown different from Heap

The String literal pool is a part of the heap.

@Prateek: you are calling the toString method of StringBuilder class not String class. What I said was about toString method of String class...

[Prateek Rawal]

Then what does toString() of StringBuilder do, please answer with reference to this code:

    public class A1  {        
   2.         
   3.         public static void main(String argv[]) {          
   4.      StringBuilder s1 =new StringBuilder("apple");//line 1        
   5.      s1.toString();// line 2        
   6.       //line 3            
}  }       

[Petar Thomas]

Returns a string representing the data in this sequence. A new String object is allocated and initialized to contain the character sequence currently represented by this object. This String is then returned. Subsequent changes to this sequence do not affect the contents of the String.

quote source:
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/StringBuilder.html

EDIT:
I appologize, on second look I am not 100% sure what's happening.

[Ankit Garg]

public static void main(String argv[]) {          
     StringBuilder s1 =new StringBuilder("apple");
     s1.toString();
}

Two String objects will be created here, one in the pool and one created by the toString method of StringBuilder class...

[Petar Thomas]

Funny

[Prateek Rawal]

where does the string object created by toString() method of StringBuilder get created?

In the non-pool memory i suppose, as one String object with same value is already there in the pool
Correct me if i'm wrong

[Abimaran Kugathasan]

Prateek Rawal wrote:where does the string object created by toString() method of StringBuilder get created?

In the non-pool memory i suppose, as one String object with same value is already there in the pool
Correct me if i'm wrong

Strings are immutable because String literals with same content share the same storage in the string common pool. Modifying the content of one String directly may cause adverse side-effects to other Strings sharing the same storage. JDK provides a StringBuffer class (in package java.lang) to support mutable strings. A StringBuffer object is just like any ordinary object, which are stored in the heap and not shared, and therefore, can be modified without causing adverse side-effect to other objects.

StringBuilder and StringBuffer are almost same except the synchronization, so

StringBuilder s = new StringBuilder("ABC");

will create a StringBuilder object in the heap not in the String Literal Pool, But

s.toString();

will create a String object in the String Literal Pool necause there is no ABC literal in that pool.

Check the toString() method API of the StringBuilder.

[Prateek Rawal]

IMO you are slightly going wrong,

see,

   StringBuilder s = new StringBuilder("abc"); 

will first see if the string pool has a "abc" string literal object,
1) if it does, then the reference to that literal object is retrieved and then passed in the constructor of StringBuilder to create a new StringBuilder object with same value "abc"
2)if it does not have a "abc" string literal object, then a new literal object is created in the pool and then its reference is fetched and passed in the constructor of StringBuilder to create a new StringBuilder object with same value "abc"

And now Ankit is saying,

 s.toString()   

creates a new String object(with value "abc") may be in the non-pool memory as one exists in the pool already(but i asked him and he is yet to confirm it)

What say?

[Abimaran Kugathasan]

Prateek Rawal wrote:IMO you are slightly going wrong,

So, waiting for somebody....

[Prateek Rawal]

Hey, i felt what you suggested is not correct, it's an opinion, thats it!
Don't take it otherwise and before we come to conclusion, we should always get opinions of as many as we can, right?

I wrote down the code and explanation(what i feel is correct) just so that you can ponder over it and rethink and suggest something...

[Ankit Garg]

Abimaran Kugathasan wrote:

StringBuilder s = new StringBuilder("ABC");

will create a StringBuilder object in the heap not in the String Literal Pool, But

s.toString();

will create a String object in the String Literal Pool necause there is no ABC literal in that pool.

The toString method of StringBuilder class clearly states that it creates new String object. Every String object that is created is not added to the String literal pool. The String literal pool only contains String literals of programs. The statement

StringBuilder s = new StringBuilder("ABC");

will create a String in the pool which will have the value "ABC" and also a StringBuilder object in the heap. Then s.toString(); will create another String object with the value "ABC" in the heap (not in the pool)...

[Prateek Rawal]

which means i was thinking correct....

Thanks Ankit!!!

Thanks Abimaran

[Henry Wong]

Just pointing out... that although this is really interesting, it is going deep into the implementation territory, and hence, subject to change ... and way out of scope for the SCJP exam.

Henry