Java objects, reference variables and the garbage collection heap

Question

I know you can create 2 object reference variables, such as:

Book b;
Book c;

And then create 2 objects and make the reference variables point to them:

b = new Book();
c = new Book();

So now there are also 2 objects in the garbage collection heap.

If you assign b reference variable to c , ie:

c = b;

1 of the objects in the GCH is now eligible for garbage collection, so you have 1 object there essentially.

BUT What if you change something about b , for example:

b.setAuthor("New Writer");

does that mean that if you used the reference variable c as such:

c.getAuthor();

it would get "New Writer" because both b and c point to the same object?

It just seems odd because intuitively I would think that if you did x = y , then y should still remain distinct from x when you change things about either after the assignment.

Answer 1

does that mean that if you used the reference variable c as such:

c.getAuthor();

it would get "New Writer" because both b and c point to the same object?

Yes, it does, at least for any object (as opposed to primitive types ). Simplest thing to do might be to write a sample program and see how it all works.

Primitive types (int, float, boolean, etc.) work distinctly, such as you describe in your x = y example.

Answer 2

To expand on the other responses, think of "c = b" as simply creating an alias or alternative name for the object that "b" already references. Actually, that's what you're doing every time you declare or assign any variable. "new Book()" creates some object in memory, but "Book b =" is what gives it a name in your program that allows you to access it.

Answer 3

Rules to keep in mind when dealing with Java:

1. Variables are not objects. Variables contain objects (or null ) -- a particular object can be stored in zero or more variables simultaneously. This does not create new objects, see #3.

2. Mutating an object mutates that object.

3. Assigning (or passing) an object does not make a copy/clone/duplicate.

While there are differences with "primitive values" and the implementation details, primitive values can be thought of as objects under the above rules : all primitive values are immutable and, if they are imagined as singletons (eg there is only one 0), then the equality ( == ) is identity-equality (thus a copy is indistinguishable). I try to avoid the term "reference": an object is itself .

Hopefully those rules and notes answer your question(s) :-)

Happy coding.

Answer 4

Since c is now a reference copy of b, any change to b will apply to c (unless they're primitives in which case value is passed on rather than address)

Here's a roundabout description of it

http://www.javaranch.com/campfire/StoryPassBy.jsp

Answer 5

This is the whole point of reference variables. b.SetAuthor(...) is effectively shorthand for [whatever b points to].SetAuthor(...) , and in this case what b points to is the same as what c points to. The 'real' object is somewhere else, and b and c are both just ways of reaching it. It's more obvious in languages with explicit pointers.

Answer 6

Think of b and c as boxes pointing to different Book objects. Now when c = b is done the c box now points to whatever b is pointing to. So both b and c reference exactly the same object. More precisely c is now an alias for b when c = b is done. Assignment means c gets the value of b. Objects are stored as references in Java so c will just get the reference that is stored in b which will reference the Book object b is referencing.

Hope this helps.