RHE question - String buffer

How many objects are created by the following code?
1. StringBuffer s1 = new StringBuffer("abc");
2. StringBuffer s2 = s1;
3. StringBuffer s3 = new StringBuffer("abc");
Ans: 3
My problem:
How 3 . Only 2 objects are created by way of new . So i think the answer shd be two.

I think answer 3 is right.
Reason: Objects are typically created with the new operator.
In the caso of s2 = s1, we can say in other words that:
StringBuffer s2 = new StringBuffer("abc"); this will certify s2 as a new object like s3 or s1.
Albert

Originally posted by padmini Babu:
How many objects are created by the following code?
1. StringBuffer s1 = new StringBuffer("abc");
2. StringBuffer s2 = s1;
3. StringBuffer s3 = new StringBuffer("abc");
Ans: 3
My problem:
How 3 . Only 2 objects are created by way of new . So i think the answer shd be two.

i dont thin thats a correct explanation. When u are asigning a object reference variable to another object reference variable u are just pointing the other object reference variable to the first one. So there is no question of a new object being created. It is a simple assignment and thats it,
I guess the answer should be 2.
Anand-

Hi,
The StringBuffer class methods actually modify the string buffer itself because it is mutable (unlike Strings which are inmutable).
With this in mind it makes sense for line 2 to create a new (empty )string buffer and then assign s1 to it.
???
Is that the right thinking?? I hope so but maybe someone else could comment too.

Bye Terry

Terence, Anand had it right. 's1', 's2' and 's3' are reference variables, not objects. Reference variables are always the same size and hold 'memory addresses'. The type, in this case StringBuffer, just defines the type of the object they will reference.
The code creates two StringBuffer objects ('new' always causes the creation of a new object).
Oops ... just saw the catch

"abc" is a String literal, so, the first <code>new StringBuffer("abc")</code> actually creates a String literal object to hold the contents of "abc" and a StringBuffer object. The second <code>new StringBuffer("abc")</code> only creates the StringBuffer object. "abc" already exists as a String literal so a new one won't be created.
Total objects: 2 StringBuffer objects, 1 String literal.
Hope that helps.
------------------
Jane Griscti
Sun Certified Programmer for the Java� 2 Platform
[This message has been edited by Jane Griscti (edited June 23, 2001).]

Originally posted by Jane Griscti:
Terence, Anand had it right. 's1', 's2' and 's3' are reference variables, not objects. Reference variables are always the same size and hold 'memory addresses'. The type, in this case StringBuffer, just defines the type of the object they will reference.
The code creates two StringBuffer objects ('new' always causes the creation of a new object).
Oops ... just saw the catch "abc" is a String literal, so, the first <code>new StringBuffer("abc")</code> actually creates a String literal object to hold the contents of "abc" and a StringBuffer object. The second <code>new StringBuffer("abc")</code> only creates the StringBuffer object. "abc" already exists as a String literal so a new one won't be created.
Total objects: 2 StringBuffer objects, 1 String literal.
Hope that helps.

---------------------------------------
Hi jane,
So you mean
StringBuffer sb = new StringBuffer(" abc")
This creates 1 StringBuffer object
and
1 String Literal object
So they make 2 .
The other String Buffer (new) creates one more.
So in all threee. Is that your answer , Jane?
Well, Jane, Just one more confusion . This is there with me for a long time. Please help me.
String s = " abc" -- Does this string literal imply that an object is being created.
or
Does it imply that it is just placed in the literal pool. so no object is being created.
some books write that it is not an object so it can never be GCed at any time. while in your eg, it seems that it is an object.
Please clarify
Padmini

Hi,
Padmani,i think you are really confused in the logic of object creation.Always remeber that the object is only created with "new operator" which allocates memory for the object.
Even in String class' case this rule is followed.
Now in the statement you wrote i.e.
String st="abc"
here st (a variable) is created refering to string literal ("abc") and it will just placed in the literal pool and no object is created.
This explaination also varifies that in the String Buffer's quest.(first posted) there are only 2 objects created.
Hope this help.
Regards,
Annie.

Padmini and Annie
The first time a String literal is encountered a String object is created.
From the Java API String class

All string literals in Java programs, such as "abc", are implemented as instances of this class.

and then from the JLS section 3.10.5

Literal strings within the same class (�8) in the same package (�7) represent references to the same String object (�4.3.1).

Padmini,
check this out:

Annie, you can create a String object just by assigning a literal value to a reference, you can do it this way expressly because of the string pool. Using the new operator allocates memory for a new object. If you did that for every String it could be very wasteful because you would be allocating more memory for every String even if they were the same. Because Strings are immutable it doesn't make any sense to keep allocating space when the variables can just be changed to reference different literals in the pool.
hope that helps,

Dave
If I'm wrong someone please fix me.

Hi ranchers,
So what is the final answer to both of my questions?
my first question on how many objects are created and
second one on whether -- String s = "abc" is a string object or not?
Well, I have though read in many books that String s = "abc" is a string constant and a string object.
Please clarify
Thanks
padmini

Hi Padmini,
I guess you are right, only 2 objects are creaed and String s="abc" is an literal not an object. SO you are right, ans. should be 2.
Jyotsna

The final answer is 3 objects as Jane said.
You create one String literal "abc" and then 2 Stringbuffer objects. Both of the Stringbuffer objects reference the same String object, but they are still objects because they were created using 'new'.
Hope that clears it up
Dave

I agree with Jane. 3 objects are created - a string literal and 2 stringbuffer objects

akila

Well Dave , alika, jane,
If according to you i assume that 3 objects are being created.
What cannot String s = "abc" - never be GCed?( I am speaking in the general context of string literals- they can never be GCEd even if set to null.)
If it is an object , it should be eligible for GC right??( Please note that the subject of GC is from the general point of view)
Please Scott, Cindy , Jane , please give a final answer. I am having my exams in a week's time.
Thanks padmini

Originally posted by padmini Babu:
Well Dave , alika, jane,
If according to you i assume that 3 objects are being created.
What cannot String s = "abc" - never be GCed?( I am speaking in the general context of string literals- they can never be GCEd even if set to null.)
If it is an object , it should be eligible for GC right??( Please note that the subject of GC is from the general point of view)
Please Scott, Cindy , Jane , please give a final answer. I am having my exams in a week's time.
Thanks padmini

I agree 3 ojects have been created!
"abs".toString=="abs";result is true;

Hello Ranchers,
I totally agree with Jane. I think, the explanation given is absolutely right.

StringBuffer confusing = new StringBuffer("Confusing");
Question: How many objects are created? please answer by number
Albert

Originally posted by Devavrat Bagayat:
Hello Ranchers,
I totally agree with Jane. I think, the explanation given is absolutely right.

Hi Albert,
StringBuffer confusing = new StringBuffer("Confusing");
creates two objects.
1 String object
1 StringBuffer object.
(look for Jane Griscis explanation. Seems correct to me.)
If you take:
String another = "Confusing";
StringBuffer confusing = new StringBuffer("Confusing");
You have 2 Objects, because
second "Confusing"-STRING (not StringBuffer) uses literal pool

correct me if i am wrong
Axel

[This message has been edited by Axel Janssen (edited June 28, 2001).]

Hi Friends,
Hi Jane,
We cannot create StringBuffer literal, i.e.
StringBuffer sb = "ABC" // not possible. Compile time error as "Incompatible type declaration. Can't convert java.lang.String to java.lang.StringBuffer.
We can create only StringBuffer object or a variable (of course, reference variable) not LITERAL.
StringBuffer sb1; // we can, it is just a reference variable.
StringBuffer sb1 = s; //we can, we are creating a variable and that varible pointing to s an object of StringBuffer.
Am I correct Jane. Please correct if I am wrong.
Thanks and regards,
V.Srinivasan
[This message has been edited by V Srinivasan (edited June 28, 2001).]

Hi,
Thanx Dave to clear my concept

.I got the point expained by by Jane and you and agree to your ans.
Regards,
Annie.

Well, how did I miss this interesting conversation?
I think we all agree that if you construct a StringBuffer object using a String literal, that the String literal has to be created as a String object first, if it does not already exist. OK.
Then V (that is a NAME - V?) just showed some stuff messing around with variables of StringBuffer type and what they are pointing to. She correctly pointed out that StringBuffers can not use String literal syntax.
The REAL issue here seems to be the confusion over Strings, literals and the constant pool.
If you have
String str = "abc";
the first thing that happens is that the JVM runs over to the Constant Pool and looks in it's literal table to see if "abc" already exists as a literal. If it is not found then a String object containing "abc" is created in the constant pool as an entry into the literal table that references the new String object so that future code can reuse the same object. Then a reference to the object is returned to the creating code, in this case the variable str now holds that ADDITIONAL reference to the String object.
Since the literal table is kept in the method area (NOT the garbage collectable heap) the reference to the String object will NEVER go away. You as a programmer can not touch that reference or null it out or anything. Even setting the variable str to null will not clear the reference in the literal table. Therefore the String object in the constant pool literal table will NEVER be garbage collected. That does not mean it is any less an object than a non-literal String, just that it has this built in protection.
If you call the intern() method on a String object you are saying "put this object in the literal table". Instant protection (yeah, yeah and effeciency and etc).
All of which is why the original code:
StringBuffer s1 = new StringBuffer("abc");
deals with 2 objects.

[This message has been edited by Cindy Glass (edited June 30, 2001).]

Cindy said it

------------------
Jane Griscti
Sun Certified Programmer for the Java� 2 Platform

hi ,
String str = new String("abc");
how many objects are created ?? two???
shanks.

One variable "str" is created on the stack.
One object holding "abc" is created on the heap.
Nothing involves the literal table in this code. When you use the "new" keyword you bypass that little efficiency.
[This message has been edited by Cindy Glass (edited June 29, 2001).]

In this case, there are only 2 object. Because:
-In line 1, a block of memory is located for "abc" in heap memory area and s1 refers to this memory. Note that "abc" is not in the pool (constant memory area).
-In line 2, s2 refers to this memory location. No new block of memory is created. So, until now, there's only one object is created.
- In line 3, a new block of memory is located for "abc". It is not the first block. This is second object.
Note that there's no "abc" in the pool
Hope it is clear!
Tuan Anh

Originally posted by padmini Babu:
How many objects are created by the following code?
1. StringBuffer s1 = new StringBuffer("abc");
2. StringBuffer s2 = s1;
3. StringBuffer s3 = new StringBuffer("abc");
Ans: 3
My problem:
How 3 . Only 2 objects are created by way of new . So i think the answer shd be two.

[This message has been edited by Anh Chu (edited July 03, 2001).]