Why does the reference-type parameter refer to the same object? Help pls
Why does the reference parameter (Y) refer to the same object which the argument reference (myObject) referring to?
Even though i have created a new object in the method.
Need some explanation here please.
The Codes:
publicclass NewEmpty{
publicstatic String x;
publicstatic String y;
public NewEmpty(String l,String m)
{
x=l;
y=m;
}
public String toString()
{
return x + y;
}
}
publicclass Test{
publicstaticvoid main(String args[])
{
NewEmpty myObject =new NewEmpty("t","r");
System.out.println(myObject);
assign(myObject);
System.out.println(myObject);
}
publicstaticvoid assign(NewEmpty y)
{
y=new NewEmpty("a","q");
System.out.println(y);
}
}
The out put is:
t r
a q
a q
Shouldn't be the output the following:
t r
a q
t r
Thanks
[2040 byte] By [
AQ_Javaa] at [2007-11-27 10:31:59]

Because you passed the value of the reference of myObject to the assign method and there you've changed that value so, myObject now has a new reference.
Check this link.
http://www.javaworld.com/javaworld/javaqa/2000-05/03-qa-0526-pass.html
Message was edited by:
manuel.leiria
Because what you pass into your assign method isn't an object, but a copy of a reference to an object. The original reference "myObject" is not affected by whatever goes on inside that method. All you've done is take the copy of the reference - the argument 'y' - and pointed it to another object
Follow teh linkz
http://www.javaranch.com/campfire/StoryCups.jsp
http://www.javaranch.com/campfire/StoryPassBy.jsp
Because there are no object variables in Java. Y is a reference variable, which is initialised to point to the same object as myObject. The reference is copied from myObject to y. Changing y doesn't change myObject, nor does it change the object myObject points to.
> Because what you pass into your assign method isn't
> an object, but a copy of a reference to an object.
> The original reference "myObject" is not affected by
> whatever goes on inside that method. All you've done
> is take the copy of the reference - the
> argument 'y' - and pointed it to another object
>
> Follow teh linkz
>
> http://www.javaranch.com/campfire/StoryCups.jsp
> http://www.javaranch.com/campfire/StoryPassBy.jsp
what i am trying here to do is assigning y to a new object.
y= new NewEmpty("a","q");
So why the object of the reference myObject is affected when i did this, shouldn't y refer to a new object and not to the old one since new keyword in the code.
> > Because what you pass into your assign method
> isn't
> > an object, but a copy of a reference to an object.
> > The original reference "myObject" is not affected
> by
> > whatever goes on inside that method. All you've
> done
> > is take the copy of the reference - the
> > argument 'y' - and pointed it to another object
> >
> > Follow teh linkz
> >
> > http://www.javaranch.com/campfire/StoryCups.jsp
> > http://www.javaranch.com/campfire/StoryPassBy.jsp
>
>
> what i am trying here to do is assigning y to a new
> object.
>
> y= new NewEmpty("a","q");
>
> So why the object of the reference myObject is
> affected when i did this, shouldn't y refer to a new
> object and not to the old one since new keyword in
> the code.
It does. Where you're falling down is that the 'y' reference is a copy of whatever was passed in to that method, the 'y' variable doesn't exist outside that method. You're essentially trying to use pass-by-reference semantics in a language that doesn't support them (despite what anyone else tells you)
The original reference you passed into the assign method still points to the old instance, and of course the new instance is up for GC once your method returns, so effectively doesn't exist any more, or isn't reachable, anyway
java passes objects by reference, references are aliases, they are additional names. dont be fooled by valoos, and read james goslings words carefully.
the right answer to op's tricky question is this:
public static void assign(NewEmpty y)
{
y= new NewEmpty("a","q");
//this y is a local variable, change it to the following
//will solve your puzzle:
this.y = new Empty("a", "q");
System.out.println(y);
}
> java passes objects by reference
No it doesn't. It doesn't pass objects at all
> references are
> aliases, they are additional names. dont be fooled by
> valoos, and read james goslings words carefully.
Additional to what? Objects don't have names. Stop trying to confuse matters
> the right answer to op's tricky question is this:
> [code]
> public static void assign(NewEmpty y)
> {
> y= new NewEmpty("a","q");
> /this y is a local variable, change it to the
> following
>//will solve your puzzle:
> this.y = new Empty("a", "q");
>System.out.println(y);
> code]
Hardly a solution
Where the OP is going wrong has nothing to do with PBR or PBV.
(S)he has declared x and y in the class NewEmpty to be static and that is why (s)he gets the behavior described.
Changepublic static String x;
public static String y;
topublic String x;
public String y;
and you will get your expected output.
dwga at 2007-7-28 18:13:27 >

I got it now
georgemc thank you very much for your time
So technically y is remote controlling the too objects at the same time, but the object created in the method will be deleted when the method return the control to the caller.
> java passes objects by reference, references are
> aliases, they are additional names. dont be fooled by
> valoos, and read james goslings words carefully.
>
That;s a misleading way to think about it. There are no object variables in Java. There are reference variables. y is not an alias for myobject, but a completely different reference variable stored in a different stack frame. It's simply that those two variables initialy point to the same object in heap.
Hence it's perfectly true that all parameters in Java methods are, indeed, passed by value but, if the parameter is an object reference, then it's the reference that's copied.
> Hardly a solution
oh, i overlooked that y is a static variable, then do this:
public static void assign(NewEmpty y)
{
y= new NewEmpty("a","q");
//this y is a local variable, change it to the following
//will solve your puzzle:
Empty.y = new Empty("a", "q");
System.out.println(y);
}
> Where the OP is going wrong has nothing to do with
> PBR or PBV.
> (S)he has declared x and y in the class NewEmpty to
> be static and that is why (s)he gets the behavior
> described.
> Changepublic static String x;
> public static String y;
topublic String
> x;
> public String y;
and you will get your expected
> output.
Well spotted!
But I bet the OP was still confused between PBR and PBV. Judging by their comments, they expected re-assigning 'y' to affect references outside of the assign() method
> > Hardly a solution
>
> oh, i overlooked that y is a static variable, then do
> this:
> [code]
> public static void assign(NewEmpty y)
> {
> y= new NewEmpty("a","q");
> /this y is a local variable, change it to the
> following
>//will solve your puzzle:
> Empty.y = new Empty("a", "q");
>System.out.println(y);
> de]
You didn't overlook it at all. You noticed our eagle-eyed friend point something similar out, and band-waggoned it. There are 2 'y' variables in the question, in different classes
> Well spotted!
>
> But I bet the OP was still confused between PBR and
> PBV. Judging by their comments, they expected
> re-assigning 'y' to affect references outside of the
> assign() method
By what the OP originally said, I'd say (s)he wasn't confused at all.
And I quote:
"
The out put is:
t r
a q
a q
Shouldn't be the output the following:
t r
a q
t r
"
Which says to me that (s)he understands that assigning to y in the assign method shouldn't affect myObject in main.
dwga at 2007-7-28 18:13:27 >

> > Hardly a solution
>
> oh, i overlooked that y is a static variable, then do
> this:
> [code]
> public static void assign(NewEmpty y)
> {
> y= new NewEmpty("a","q");
> /this y is a local variable, change it to the
> following
>//will solve your puzzle:
> Empty.y = new Empty("a", "q");
>System.out.println(y);
> de]
Empty is not a defined type and if you mean NewEmpty.y then that is neither of type Empty nor NewEmpty, but in fact a String. So this will not solve anything or even compile.
Now stop saying rubbish.
dwga at 2007-7-28 18:13:36 >

> java passes objects by reference, references are
> aliases, they are additional names.
Shutup daFei. Stop deliberately giving false information.
OP: Ignore this idiot.
jverda at 2007-7-28 18:13:36 >

> > java passes objects by reference, references are
> > aliases, they are additional names. dont be fooled
> by
> > valoos, and read james goslings words carefully.
> >
>
> That;s a misleading way to think about it.
Not misleading--flat out wrong. This is just daFei or a daFei clone, trolling and deliberately giving out information he knows to be wrong.
jverda at 2007-7-28 18:13:36 >

> Hence it's perfectly true that all parameters in Java methods are, indeed, passed by value but, if the parameter is an object reference, then it's the reference that's copied.
Welcome to the swirling vortex of ignorance collectively known as "daFei".
~
> Welcome to the swirling vortex of ignorance
> collectively known as "daFei".
>
> ~
yours are worse:)
> > Welcome to the swirling vortex of ignorance
> > collectively known as "daFei".
> >
> > ~
> yours are worse:)
That pathetic attempt at a comeback doesn't even make any sense.
Go back to your hole.
dwga at 2007-7-28 18:13:36 >

> > Welcome to the swirling vortex of ignorance
> > collectively known as "daFei".
> >
> > ~
> yours are worse:)
Stunning comeback, akin to "so's your face". Lets not have any more perfectly decent threads dragged into the gutter, then oblivion, by clowns like this
> > Hence it's perfectly true that all parameters in
> Java methods are, indeed, passed by value but, if the
> parameter is an object reference, then it's the
> reference that's copied.
>
> Welcome to the swirling vortex of ignorance
> collectively known as "daFei".
>
> ~
daFei was not sure on his way of discovering the true meaning of pass by reference, he might have lost on some details living among all misleading noises. but now he is clear on everything!
java passes primitives by value, objects by reference. on a distributed system, server objects are passed by reference, serilizable objects are pased by value.
i am sorry guys to be the reason for making any trouble for some people
Ok my question now
Why when i remove the static keyword on both fields the problem solved?
Message was edited by:
AQ_Java
> i am sorry guys to be the reason for making any
> trouble for some people
The only person making trouble here is oldMan. Just ignore any "advice" from it and you'll be okay. It's a known troll.
> Why when i remove the static keyword on both fields the problem solved?
When you remove the static keyword, the variables apply only to individual instances of the class, rather than all instances of the class.
~
Because fields that are static are class fields, not instance fields.
That means that they can be accessed and mutated (if they're not final) without any need of an instance.
Exampleclass Foo {
public static String bar;
}
public class Test {
public static void main(String[] args) {
Foo.bar = "foobar";
}
}
Have a look here:
http://java.sun.com/docs/books/tutorial/java/javaOO/classvars.html
for further details.
dwga at 2007-7-28 18:13:36 >

> Empty is not a defined type and if you mean
> NewEmpty.y then that is neither of type Empty nor
> NewEmpty, but in fact a String. So this will not
> solve anything or even compile.
> Now stop saying rubbish.
ah, yes, please forgive me, i am guilty overlooking everything. the output is correct, op's expectation was not correct. thoes variables are static ones being accessed by an object, they are like singletons, once changed, they are not coming back to the initial values.
> ah, yes, please forgive me, i am guilty overlooking everything.
Yes.
~
> i am sorry guys to be the reason for making any
> trouble for some people
>
you are ok, they are valoos. dont worry about it.
> Ok my question now
>
> Why when i remove the static keyword on both fields
> the problem solved?
>
remove the static keyword, and use this.y instead of just y. y refers to the local variale, the formal parameter. this.y refers to the instance y you declared.
@OP: Please ignore anything daFei (oldMan) says if you don't want to be confused as it is all nonsense.
dwga at 2007-7-28 18:13:36 >

Thank you very much
It is now so clear to me