aspose file tools*
The moose likes Java in General and the fly likes STRING BUFFER query Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "STRING BUFFER query" Watch "STRING BUFFER query" New topic
Author

STRING BUFFER query

Dinesh Arora
Greenhorn

Joined: Apr 18, 2007
Posts: 21
I have a doubt in this question:
GIVEN:
public class test{
public static void main(String [] arg){
String a = new String("A");
StringBuffer b = new StringBuffer("B");
stringOp(a);
bufferOp(b);
System.out.println(a +"," + b);
}
static void stringOp(String x){
x=x.concat("z");

}
static void bufferOp(StringBuffer y){
y = y.append("U");
}
}

Question:
WHAT IS THE OUTPUT?

According to me, since java uses only pass by value. The output should be
- "A,B"

However the actual output is "A,BU". I understand that both String and StringBuffer are objects. "U", whould not have been appended to String buffer, since only a copy of value is sent as argument. The variable 'y' should have perished as soon as method returns to main and the original value value of StringBuffer b --> "B", should have been maintained. Can any one explain why this does not happens?

Also I was going through some of the questions in "TEST KING" and they have a number of questions wrong, along with numerous printing mistake. Cn some one suggest me a good source of question bank as well.

Thanks,
Dinesh
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39408
    
  28
You are right about Java only supporting pass-by-value, but you need to consider which value you pass.

You pass a number which provides access to a String content "A" to the stringOp method. So the method picks up the String object, and performs a concatenation operation on it. The String a is not changed in its original memory location, and the parameter x behaves like a local variable; it vanishes into cyber-limbo. So the first part of the printout is "A".

You pass a number which provides access to a StringBuffer (BtringBuilder would have been better) content "B". The method gains access to that Object, so the buffer b and the parameter y refer to the same object. Then the method concatenates "U" making "BU." Then (remember the = operator has a low precedence) it sets the object y equal to itself (!)
Now, you have manipulated and altered an object. So when you go back to the original method, you find the object has become BU. So you print out A,BU.

[edit]Add: Reason you can't change Strin gin its original location: you can't change Strings at all; they possess no methods for changing.[/edit]
[ April 29, 2007: Message edited by: Campbell Ritchie ]
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39408
    
  28
More about this:

Whenever you pass the value of a primitive type, there is no way one can change anything in the original value.

Whenever you pass the value of the location of a reference type, you are permitting the state (fields) of the reference type to be changed (within the normal rules of method access). Most classes (including your StringBuffer) have methods which permit one to change their state, which is exactly what you are doing here. The y = bit has no effect; you are simply setting a value equal to itself. What happened to your StringBuffer is the normal behaviour for objects passed to methods.
The reason you get no change to the String A is that Strings have no methods allowing changes to their state (content). That is why they are called immutable here.

CR

[edit]Minor spelling and similar corrections[/edit]
[ April 30, 2007: Message edited by: Campbell Ritchie ]
Burkhard Hassel
Ranch Hand

Joined: Aug 25, 2006
Posts: 1274
Hi ranchers,

im only repeating Ritchie, but maybe it helps if you read the same issue in two ways of explaining.

First a short cut of Dinesh's code, not regarding "normal" objects like StringBuffers:

prints only an A. Why?

Because Strings are immutable.
The "A" object from main will never change.
At the first line of main(), variable a refers to this immutable "A" object.

stringOP(a); then calls the method.
Within the method you have variable x. Variable x is a copy of variable a. That means, it initially refers ("points to") the same object as a: The "A" object created in main().
Note, it is a copy of the variable, NOT of the object!

Now comes the bold line:
x = x.concat("B");

As Strings are immutable, the line creates - without using the new operator - a new String object. It has to create a new String-object, because the original object cannot be used, as it is immutable!
The new object is made using x.
x still points to the "A"-object. The new object is made by taking this "A" object and appending a "B".
Now the x refers to this new "AB" object. It no longer refers to the "A" object. Variable x has been re-referenced.

And variable a?
Well, it still refers the good old immutable "A".
When you say "print(a)", the output is "A".
As Ritchie already said, the "AB" (or "Az" in the original code) is gone. It can be found at Oblivion - Main Station, Track 9 3/4.


And the StringBuffer?
The different behaviour of the String buffer comes from the fact, that it is not immutable. It is just an ordinary object.

[conjunctive]
If there was a StringBuffer and not a String in class ShortCut:
x = x.append("S");

it would not be necessary to create a new StringBuffer object.
The x would refer to the original "A" StringBuffer object, an "S" would be glued after it, and the method ends. The original (and only) object would have been changed.

variable a still would refer to the same - but now changed! - object.
[/conjunctive]

By the way, in the original code from Dinesh,
the y= in y=y.append("U"); is not necessary to get the same output (true also for the x=). Perhaps you know now why.


Yours,
Bu.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: STRING BUFFER query