Another passing by reference question

[Vonique Leary]

[size=12][color=darkblue]I quoted the below paragraph from this site's "pass by value" section:


"

Cat A = new Cat();
doStuff(A);

void doStuff(Cat B) {

   B = new Cat(); //did NOT affect the A reference
}

Doing this simply "points" B to control a different object. A is still happy.


There is still just ONE Cat object. But now TWO remote controls (references) can access that same Cat object.

So now, anything that B does to the Cat, will affect the Cat that A refers to, but it won't affect the A cup!"

Just when I think I'm understanding what it means to pass by value and pass by reference, I read something like the above and get confused again. What puzzles me is this:

A new Cat object has been created in line 1; that reference (A) then is passed to the doStuff method where it is now assigned to a new Cat object.

Question: Reference A points to new Cat before it gets passed to the doStuff method. Now A points to another new Cat object. Can one reference point to two difference objects? In the method definition:

void doStuff(Cat B) {

   B = new Cat(); //did NOT affect the A reference
}

Does reference A not replace B and assume all the things that are going to happen to B? And isn't B creating a new Cat? How can A point to two different Cats?

Can someone straighten me out? I know I'm missing something important.

Thanks, Von[/color][/size]

[Samrat Som]

I do Understand that it creates a confusion when you are a beginner....But Let me help you out...
When reference of A is being passed to function doStuff(). The reference copy is being passed to the refernce B.

Initially
A-----> | Class Cat |
Then When DoStuff being called
A-----> | Class Cat | <--------B

When the new operator is again being called it takes a free memory from the heap and creates a class type and reassign it to class B
so it looks like this

A-----> | Class Cat |

B-----> | Class Cat |

I hope I made you understand

[Vonique Leary]

Not really because from your explanation (and the paragraph I quoted) it seems as though B is an object in and of itself. But what I have learned about methods is that they contain parameters which represent the arguments that will be supplied when the caller calls the method. In this case, that is reference A. So I assume that argument A is going to take the place of parameter B. If I am correct, then when the method says that there is going to be a new Cat created which is B, I am assuming that when the method is called, the B is really going to be replaced by A.

So that brings me round again to:

Can A point to two different objects?

What am I doing wrong?

Thanks, Von

[Antany Vasanth]

Hi Leary

Consider A and B are just the name which refers the memory location of the Object

A ---> Memory Location Of Object A

After passing the A's reference to B refers the memory location of the Object A.

B ---> Memory Location of Object A

But after creation of new object, the new object is created and stored in new memory location and B refers that new object as like below

B ---> Memory Location of Object B

In the above case, B's reference is changed But the A's reference still pointing to the A's Object

Regards,
Antany

[Joanne Neal]

The text you quoted

There is still just ONE Cat object. But now TWO remote controls (references) can access that same Cat object.

So now, anything that B does to the Cat, will affect the Cat that A refers to, but it won't affect the A cup!"

referred to a slightly different piece of code in which the doStuff method was empty. The B = new Cat(); line was not added until later.
With this in mind try reading the article again and see if it makes sense now

[Vonique Leary]

Oh, I see my error now. But still have a question regarding the following:

  

Cat A = new Cat();
doStuff(A);

void doStuff(Cat B) {

   // use B in some way
}
  

"There is still just ONE Cat object. But now TWO remote controls (references) can access that same Cat object.

So now, anything that B does to the Cat, will affect the Cat that A refers to, but it won't affect the A cup!

You can change the Cat, using your new B reference (copied directly from A), but you can't change A. "


When the B reference is copied directly from A, why isn't that the same reference? Are there now two A references? I have trouble thinking of B as an actual reference since it is only a parameter to be replaced by A.

Where am I going wrong?

[Campbell Ritchie]

It might be better if they had said you can "change the state of the Cat," rather than, "change the Cat".

You create a Cat reference and call it A and (immediately afterwards) create a Cat object and apply the name A to it.
Then you do pass-by-value (Java™ does not support pass-by-reference) and the doStuff() method can do things to the Cat, but cannot swap A for a different cat.

Real cats support this behaviour well. If your tabby cat is hungry, it will happily pass itself by value to the neighbours and beg food. So the neighbours can convert your hungry cat to a fed cat, but they cannot swap your tabby cat for a black cat. Even if they chuck your cat out, and find a black cat and feed it instead, when your tabby cat wanders back (still hungry and the neighbours didn't feed it ) you will recognise it as the same cat you had before.

Your Cat object which A points to will be the same Cat object. If the doStuff method feeds said Cat, then it will cease to be hungry. If the doStuff method replaces it with a different Cat, there is nothing that method can do with the Cat at A. That Cat object remains. The new Cat object might do things, eg purr() chaseMouse() onlyEatAtTheNeighbours(), and might vanish at the end of the method, but you cannot change which Cat is referred to by "A".

[Campbell Ritchie]

Let's try a different approach.

"Cat A" means let's make space somewhere for a Cat
"= new Cat();" Create a Cat object at memory location 1234abcd, which you are applying the name A to.
[Note there is no simple way to get at the memory location; 1234abcd is obviously a guess.]
public void doStuff(Cat B) = We have a method, which takes a Cat reference, and in the method we apply the name B to it.
The JVM will pass 1234abcd to that method meaning, "This is the Cat object I want you to deal with."
doStuff(A) = Let's call that method and tell them to do it to our Cat A. We call it "A" (you call your tabby "Tiger") but in the method they will call it "B" (when Tiger goes next door for food, the neighbours say "Fluffy"). At this point, yes we have one Cat at 1234abcd which has two names.
If you wrote "B.eat();" that would mean "feed the cat we call B/Fluffy, and the same Cat which the other people call A/Tiger ceases to be hungry."
If however you write "B = new Cat();" it means create a new Cat object (maybe black cat called Tibbles at memory location 2345bcde) and use that instead of "B". The Cat at "A" (1234abcd/Tiger/Fluffy) is now ignored and wanders home.

Try as you may, you cannot say B = inside that method and make A point at a different Cat. If you search this forum for "pass by reference Pascal" you find that you could make A point to a different Cat if you wrote in Pascal (similarly in C++), but you can't do that in Java™.

Note your Cat objects only have one memory location or identity (at a time; the actual location can change) but can have several names.

[Narendira Sarma]

Campbell Ritchie wrote:
If however you write "B = new Cat();" it means create a new Cat object (maybe black cat called Tibbles at memory location 2345bcde) and use that instead of "B"

That made me understand. Thanks Ritchie.

[Campbell Ritchie]

You're welcome

[Vonique Leary]

So then this code:

  void doStuff(Cat B) {   
  
   B = new Cat(); //did NOT affect the A reference   
}  
  

means that a new cat was created, and the original that was created (Cat A = new Cat(); ) before the method was invoked does not exist anymore? Why does it say that the A reference was not affected, if we put doStuff(A)?

[Campbell Ritchie]

Cat A = new Cat();
doStuff(A):
. . .
A.purr();

This will demonstrate that A still exists, even though doStuff() has lost contact with it. This is the cat that wandered home hungry that I mentioned earlier.

So Cat A is still there. Only the doStuff method has lost contact with that Cat. And if you are a real cat-lover, don't read this link, least of all the bit about "how to wash a cat" by "picnikel"

[Vonique Leary]

So, let me see if I am getting this correctly: That first A Cat still exists but it is no longer being referred to by this A, which refers now to Cat B because of the invocation of the doStuff method?

(I'm a serious cat lover).

[Campbell Ritchie]

'Fraid not.

The Cat "A" still exists and is still referred to by "A". You still have a tabby, still called Tiger.
You told method doStuff to do it with "A" = tabby = Tiger.
The doStuff people decided to call the cat they are doing it with "B".
Then they decided to do the "stuff" with a black cat called Fluffy instead.
That doesn't affect your tabby called Tiger at all.
The Cat which was previously referenced by "A" has not changed. "A" still refers to the same Cat as before.

[Campbell Ritchie]

public class CatDemo
{
    public static void main(String[] args)
    {
        new CatDemo(new Cat(args[0], args[1])).go();
    }//end main
    
    private Cat A;
    
    public CatDemo(Cat cat)
    {
        A = cat;
    }//end constructor
    
    private void go()
    {
        System.out.printf("Before calling doStuff: Cat \"A\" = %s%n", A);
        A.purr();
        doStuff(A);
        System.out.printf("After calling doStuff: Cat \"A\" =  %s%n", A);
        A.purr();
    }//end go
    
    private void doStuff(Cat B)
    {
        System.out.printf(
                "In doStuff method, before reassigning \"B\":%nB = %s%n", B);
        B.purr();
        B = new Cat();
        B.purr();
        B.feedMe();
        System.out.printf(
                "In doStuff method, after reassigning \"B\" to \"new Cat()\": black Fluffy%nB = %s%n",
                B);
        B.purr();
    }//end do stuff method
}//end cat demo class    

public class Cat
{
    private static int idNumber = 0;
    
    private int id;
    private String name;
    private String colour;
    private boolean isHungry;
    
    public Cat(String name, String colour)
    {
        this.name = name;
        this.colour = colour;
        isHungry = true;
        idNumber++;
        id = idNumber;
    }//end contructor
    
    /**
     * Constructor with default values colour = black, name = Fluffy
     */
    public Cat()
    {
        this("Fluffy", "black");
    }
    
    /**
     * I am suffering an almost overwhelming urge to call this method
     * "feedMeSeymour()"
     */
    public void feedMe()
    {
        isHungry = false;
    }//end feed me method
    
    public void purr()
    {
        System.out.println(isHungry ?
                "Hiss! Spit! WaaaaaaaaaH!" : "Prrrrrrrrrrrrrrrr");
    }//end purr method
    
    @Override
    public boolean equals(Object o)
    {
        /*
         * The id number is not taken notice of in this method
         */
        return o == this ||
            (
                o != null &&
                o.getClass() == getClass() &&
                (name == null ? ((Cat)o).name == null : name.equals(((Cat)o).name)) &&
                (colour == null ? ((Cat)o).colour == null : colour.equals(((Cat)o).colour)) &&
                (isHungry == ((Cat)o).isHungry)
            );
    }//end equals
    
    @Override
    public int hashCode()
    {
        return ((("Cat".hashCode() + name.hashCode()) * 31 +
               colour.hashCode()) +
               (isHungry ? 1 : 0)) * 31;
    }//end hash code
    
    @Override
    public String toString()
    {
        return "A " + colour + " cat called " + name + " No " + id + ", which " +
                (isHungry ? "wants some dinner." : "won't eat even prime salmon now.");
    }//end to String
}//end Cat class    

campbell@queeg:~/java$ javac CatDemo.java
campbell@queeg:~/java$ java CatDemo Tiger tabby
Before calling doStuff: Cat "A" = A tabby cat called Tiger No 1, which wants some dinner.
Hiss! Spit! WaaaaaaaaaH!
In doStuff method, before reassigning "B":
B = A tabby cat called Tiger No 1, which wants some dinner.
Hiss! Spit! WaaaaaaaaaH!
Hiss! Spit! WaaaaaaaaaH!
In doStuff method, after reassigning "B" to "new Cat()": black Fluffy
B = A black cat called Fluffy No 2, which won't eat even prime salmon now.
Prrrrrrrrrrrrrrrr
After calling doStuff: Cat "A" = A tabby cat called Tiger No 1, which wants some dinner.
Hiss! Spit! WaaaaaaaaaH!

[Vonique Leary]

The Cat which was previously referenced by "A" has not changed. "A" still refers to the same Cat as before.

I'm going to have to study the code you posted (thank you for all that hard work, and I promise I am not ignoring it, but I just want to ask a question).

If "A" first refers to the Cat A, and then when put in doStuff, now refers to the new cat "B", can one reference refer to two objects? Does "A" after being passed to doStuff refer to that cat and the first cat outside the method?

Simple question, simple answer, if possible.

Thanks, and I"m sorry I'm such a stupidhead.....

[Vonique Leary]

  void doStuff(Cat B) {      
     
   B = new Cat(); //did NOT affect the A reference      
}     
    
  

I think one of my problems is that I may be referring to different code than you are. I'm referring to the above when I asked my last question. How can A refer to A and B?

[Campbell Ritchie]

No, you cannot have one reference to two objects simultaneously.
At the beginning of the doStuff() method you have both "A" and "Cat B" referring to the same object. Then later on, you change what "B" refers to.
And my code includes both . . . void doStuff(Cat B) . . . and . . . B = new Cat();. I made sure it had the same code in as you quoted. The print statements are to allow you to see the details of the cats you have. The id number is different in each instance but is not changed. I ran the code again after changing

public class Cat
{
 . . .    
    private int id;

to

public class Cat
{
 . . .    
    private final int id;

and I got exactly the same output as I showed you last night. You can tell which Cat object is which because one has No 1 and the other No 2. It is rather like putting a microchip into the cat so you can identify it if it is found a long way from home.

You are going to have to resort to old-fashioned method. Pencil and paper. Print out some code, and at the end of each line write down the references and the objects. So you would start with

public class CatDemo
{
    public static void main(String[] args)
    {
        new CatDemo(new Cat(args[0], args[1])).go(); // Unnamed reference ---> Cat no 1.
    }//end main
    
    private Cat A;   // Reference A ---> null
    
    public CatDemo(Cat cat)
    {
        A = cat;  // Reference A ---> same as "unnamed" above = Cat No 1
    }//end constructor

Keep going until you reach the end of the code. The bits about hiss spit and prrrrrrrrrrrr are there so you can see which Cat is hungry and whether it purrs nicely or not. You might write
D ---> Cat no 3: hasn't had dinner: expect it to say hiss spit.

[Vonique Leary]

Okay, I will try the paper and pencil method. Can you believe how dense I am? I think I do understand it but when I see all that code I get confused again. But thank you. You have put very much effort into trying to fit it into my thick head.

I will let this settle into my head for a few days and then try it again.

Thank you!

Von

[Vonique Leary]

Just a quick question:

No, you cannot have one reference to two objects simultaneously.
At the beginning of the doStuff() method you have both "A" and "Cat B" referring to the same object. Then later on, you change what "B" refers to.

When you say you change what B refers to, this is really A, correct, because A is passed into that method? So, while A is the reference to the new Cat, what is referring to the CAt that A used to point to?

Thanks,
Von

[fred rosenberger]

let's try it this way... let's assume each Cat object on the heap has a String component with the cat's name.

so you have in your main:

Cat A = new Cat("Fluffy");
A.printName();                            //line 1
myMethod(A);                             //line 2
A.printName();                            //line 3

then you have

public void myMethod (Cat B)
{
    B.printName();                       //line 4
    B = new Cat("Spike");             //line 5
    B.printName();                       //line 6
}

so you create the Cat object with the name "Fluffy", and assign reference 'A' to point to it. on line 1, you print the name of the Cat 'A' refers to, so you see "Fluffy".

you now go into the method. The reference 'B' points to the same Cat object as what 'A' points to. So, on Line 4, you will again get "Fluffy".

on line 5, you CHANGE what cat 'B' refers to - but 'A' is unchanged. You have created a brand new Cat with a new name, and changed 'B' to point to it instead of the old Cat object "Fluffy". (Inside this method, the reference 'A' doesn't really exist, or at least you can't really get to it, although the OBJECT it points to still does). you create a new cat named "Spike", and have 'B' now refer to it. On line 6, when you printName() that B refers to, you will print out "Spike". Now you fall back to line 3. Since A still refers to the same cat it always referred to, it prints "Fluffy" again.

if myMethod had looked like this:

public void myMethod (Cat B)
{
    B.printName();                       //line 4
    B.changeName("Spike");         //line 5
    B.printName();                       //line 6
}

on line 5, you change the name of the cat B is pointing to - which is the same cat 'A' is pointing to. So when you drop back to line 3, you will see the name change reflected.

[Campbell Ritchie]

Vonique Leary wrote:When you say you change what B refers to, this is really A, correct, because A is passed into that method? So, while A is the reference to the new Cat, what is referring to the Cat that A used to point to?

You start off with B pointing to the same Cat that A points to. Fred called it Fluffy, I called it No 1. A points to Fluffy/No 1. The Cat in the memory location which A points to is Fluffy/No 1.
Then you change B inside the method to a different Cat, Fred's Spike and my No 2. But the "A" reference in the other method still points to Fluffy/No 1.

How did you get on with your pencil and paper?

[Vonique Leary]

(Inside this method, the reference 'A' doesn't really exist, or at least you can't really get to it, although the OBJECT it points to still does)

This is the part I don't get. I understand the object Fluffy Cat still exists but what happened to the reference "A"? Because if you have passed "A" into myMethod, then why doesn't it exist? And what points to Fluffy Cat now?

I'm understanding it more with each explanation, so please bear with me. I think I do understand it deep down but some of the wording might be throwing me off (which isn't hard to do with me ).

Thanks, Von

[Vonique Leary]

Campbell,

But the "A" reference in the other method still points to Fluffy/No 1.

When you say "the other method" does this mean that A in the first method call is still referring to Fluffy, but A in the second call now points to the other cat?

If I were a drinker, I'd be getting the wine out by now.

Thank you for your patience.

I tried to run the program but got some error messages, so I couldn't go further with it until I figure out what I did wrong with it.

[fred rosenberger]

probably a more correct way of saying "pass to the method" would be "make a copy of the value". remember. 'A' simply holds the address of where the real object is. So when you 'pass A into the method', you make a copy of the address and paste it into 'B'.

It's kind of like a stack of papers. you're in your main method, that's one piece of paper on your desk. you have your variables like 'A' that you can see.

When you call a new method, that's like slapping a second piece of paper on top of the first. You can explicitly copy a few values onto the new piece of paper, so your 'B' on paper #2 (now on top) has the same value as 'A' on paper #1 - but you can't see paper #1. It's still there, you can get back to it, but only after you get rid of paper #2. If you change what address you store on paper #2 and 'B', that doesn't change paper #1 or 'A'.

once you are done with paper #2, you throw it away. 'B' is now gone forever, and you can once again see 'A'.

[Campbell Ritchie]

Vonique Leary wrote:When you say "the other method" does this mean that A in the first method call is still referring to Fluffy, but A in the second call now points to the other cat?

If I were a drinker, I'd be getting the wine out by now.

Can I have a drink, too, please?

Yes, A in the first method still refers to Fluffy and you pass the number for A to the other method and now call it B. At that point both point to Fluffy. Then you change B so it points to a new Cat. But the original A still points to Fluffy.

Another analogy. . .

In the next post.

[Jason Irwin]

Why not take Cambpell's code and make a really simple class out of it, just to see what happens? This thread has been going on a while, so here you go

public class Cat
{
    public String name=null;  //You should really use a getter and a setter, I won't

    public Cat(String name)
    {
    	this.name = name;
    }
    
    public static void main(String[] args)
    {
        Cat a = new Cat("Fluffy");  //Our new cat, ain't he cute?
     	System.out.println("1 Main: 'a' cat called, " + a.name);
     	
        useBWithNewCat(a);
     	System.out.println("5 Main: 'a' cat still called, " + a.name);
        
        useBWithSameCat(a);         //Ooo, I wonder what this will do?
     	System.out.println("8 Main: 'a' cat now called, " + a.name);
    }

    static void useBWithNewCat(Cat b)
    {
     	System.out.println("\t2 useBWithNewCat: 'b' cat called, " + b.name);
     	
    	b = new Cat("Spike");       //Now create a new cat as assign b to that!
    	System.out.println("\t3 useBWithNewCat: new 'b' cat called, " + b.name);
    	
    	b.name = "Tom";
    	System.out.println("\t4 useBWithNewCat: 'b' cat renamed to, " + b.name);
    }
    
    static void useBWithSameCat(Cat b)
    {
     	System.out.println("\t6 useBWithSameCat: 'b' cat called, " + b.name);
     	
    	b.name = "Tom";
    	System.out.println("\t7 useBWithSameCat: 'b' cat renamed to, " + b.name);
    }
}

At output 5, the name of a's cat is unchanged. Why? Didn't b change it? No! When b changed the name, it was pointing at a totally different object. The "b = new Cat();" did away with the a reference passed in and set it to a new one.
But on output 8 a's name is now "Tom". Why? Because b was still the same value as a, thus pointing to the same object; so whatever happened to b, happened to a.

I hope this very, very simple class is clear enough to show what is happening. This code runs (I've just tried it).

Bit more technical, but still crude:
Think of a reference to an object on the heap like an address on a piece of paper.
a and b are just those bits of paper and a reference is just a fancy way of saying address (don't tell the C programmers...)

So when the methods "useBWithNewCat" and "useBWithSameCat" are called, whatever was on a's bit of paper is copied on to b's. b is a totally different reference from a, but it happens to have the same value; the same address.
So when the JVM asks b what address it has, it winds up at the same place as when it asks a ("Fluffy").
Thus any changes to b affect a; they point to the same thing and this is what happens in "useBWithSameCat".
And by "change" I mean "b.name=...." this says "Follow b's address, find the 'name' on it and set it to this new value".

In "useBWithNewCat" we have the line "b = new Cat():", what this does it [i]erase b's bit of paper and write a new address on it[/b].
Now when the JVM ask b for the address, it ends up somewhere quite different.
So any changes to b no longer affect a; b is not point at the same object...err..I mean cat.

This means in "useBWithNewCat" after the "b= new Cat();" I can change b's name as much as I like and a will never know.
If, however, I tried that before the "b= new Cat();", then b would have the same address as a and a's name would change; just like in "useBWithSameCat".

[Jason Irwin]

Campbell Ritchie wrote:Another analogy. . .
In the next post.

Are you psychic?

[Campbell Ritchie]

Another analogy, caused by thinking "those numbers point to Cat Fluffy and Cat Spike" and "copy of."

Imagine you give me a piece of paper with your phone number copied on it. Then Rob Prime, in a moment of naughtiness, swaps the paper for one with Joanne Neal's phone number. So I pick up the paper, ring that number, and say, "Hello, Vonique."
"Whom are you calling Vonique? I'm called Joanne."

. . .

But your phone number hasn't changed.

I don't know whether that helps; if it doesn't, forget it.

[Campbell Ritchie]

Jason Irwin wrote:Are you psychic?

No, but I soon shall be

[Jason Irwin]

Campbell Ritchie wrote:Imagine you give me a piece of paper with your phone number copied on it. Then Rob Prime, in a moment of naughtiness, swaps the paper for one with Joanne Neal's phone number. So I pick up the paper, ring that number, and say, "Hello, Vonique."
"Whom are you calling Vonique? I'm called Joanne."

Never happen. The compiler (wife/partner/significant other) would throw an Exception.

[Campbell Ritchie]

More likely Rob would be blackmailing me Threatening with exposure to all three women

[Vonique Leary]

I think I've finally got it! This code helped alot!

Yes, A in the first method still refers to Fluffy and you pass the number for A to the other method and now call it B. At that point both point to Fluffy. Then you change B so it points to a new Cat. But the original A still points to Fluffy.

And Fred's paper stack analogy too!

So now I'm going to print out all these answers and study them until it is solid, but I think I'm on my way! And I'm going to load in Jason's code.

But for now, where's the wine???

Thanks everyone!

I'll post my own code in a few days that shows I understand all this craziness.....

[Campbell Ritchie]

Vonique Leary wrote:But for now, where's the wine???

I though you were buying

Thanks everyone!

You're welcome

[Nitish Bangera]

May be its a bit late but this is the code that you posted

 Cat A = new Cat();
doStuff(A);

void doStuff(Cat B) {

   B = new Cat(); //did NOT affect the A reference
}  

Say Cat has a bit pattern 11011101(Assume it) to get to Cat object. So during passing primitives the bit pattern is passed. So here the bit pattern of the reference variable is passed. Now in the method Cat B get's it. So B holds 11011101 which is wow to get to the object of Cat which is there in the heap already which is also referenced by A. Now A==B and A.equals(B) are true(logically).

but then a new object is created and the Bit pattern of B is changed because now using B we can get to some other object. Now say B has 11110101 which is not the same. Now A!=B because they have 2 different bit patterns in a nut shell referring to 2 different objects. After the dostuff method, the reference variable is dead so that object is gc'd because the bit pattern is gone. But the A's bitpattern is still there means the object is still be reached from the program.

if the code is modified a little bit then the original object is gc'd

 Cat A = new Cat();
A = doStuff(A);

Cat doStuff(Cat B) {

   B = new Cat(); //did NOT affect the A reference
return B;
}    

here the bit pattern of B is given to A.

[Joanne Neal]

How did Rob get my number ?

[Campbell Ritchie]

Robin Lane told him.

[Vonique Leary]

After the dostuff method, the reference variable is dead so that object is gc'd because the bit pattern is gone.

I thought I understood this because it makes sense that the object is gc'd since the bit pattern is gone, until I read what you wrote next:

But the A's bitpattern is still there means the object is still be reached from the program.

So that makes me ask, how can the A's bitpattern be reached if the bit pattern is gone and the reference is not there?

[Jason Irwin]

Simple A != B

Look at the "doStuff" method. "B = new Cat();" Remember what that means? B has it's bit of paper wiped and a new address (reference, bit pattern, call it what you will) written on it. This points at a new Cat on the heap.

A is still pointing at the old Cat. A's bit of paper (address/reference/bit pattern) has not been changed.

At the end of "doStuff", B goes out of scope (the paper is torn up). Nothing is now pointing at the new Cat, so it is eligible for garbage collection.

A, because it was unchanged, is still pointing at the old Cat; so that old Cat is not eligible for garbage collection.

You have to to make sure you understand what happens when "B = new Cat();" runs. This does not, and never will, have any effect whatsoever on A. B is a copy of A, it has/is a different bit of paper.

My code demonstrates this.

[fred rosenberger]

When you get down to the nitty-gritty details of how code works when calling methods, they actually talk about a 'stack'. Each method's variable's live in what is called a "stack frame" (i think). the term comes from one of those spring-loaded plate dispensers in a buffet or cafeteria where you can put a plate on the top (and push the stack down), or take the top plate off (and the rest pop up).

Part of the memory java uses is referred to as the stack. it can be thought of as a long series of bytes of memory. there is another special variable used called the stack pointer, which always points to the top of the stack. So memory-wise, a 'push' copies data into the top-most memory spots and moves the pointer up, and a 'pop' just lowers the pointer down (old data doesn't need to be erased, since it will simply be overwritten the next time you do a 'push').

Each time you call a method, a new 'stack-frame' is pushed onto the stack. It contains all the variables for that method. So, when you're in your main, it would look something like this:

stack pointer ->                                      //this is the next available spot, contains garbage
                     end of main stack frame
                     A -> refers to some other memory spot not in the stack
                     beginning of main stack frame
----------------------------------

now you call myMethod, and a new stack frame gets pushed onto the stack

stack pointer ->                                      //this is the next available spot, contains garbage
                     end of myMethod stack frame
                       B -> refers to some other memory spot not in the stack where "Spike" lives
                     beginning of myMethod stack frame
                     end of main stack frame
                       A -> refers to some other memory spot not in the stack where "Fluffy" lives
                     beginning of main stack frame
----------------------------------

Note that at any given moment, you can only get to the variable in the current, topmost stack frame. So, while you are in myMethod, you can only see 'B'. 'A' still exists in the stack frame, and you can get back to it, once you leave myMethod. Since we currently have an active reference to "Fluffy", it's NOT eligible for GC.

now we leave myMethod, and the stack pointer get moved down:

                       end of myMethod stack frame
                         B -> refers to some other memory spot not in the stack where "Spike" lives
stack pointer ->beginning of myMethod stack frame   //this is the next available spot, contains garbage
                     end of main stack frame
                       A -> refers to some other memory spot not in the stack where "Fluffy" lives
                     beginning of main stack frame
----------------------------------

Notice something interesting... all I did was move the stack pointer down. We can now only get to what is in the top stack frame, which in this case is the "main". I CANNOT access anything above the stack pointer, because by definition it not being used by my program. at this point, if the above code is complete, "Spike" is eligible for GC, since there is no active reference to it. there has always been an active reference to "Fluffy", even if we couldn't get to it while in myMethod.