When I sent an object to another class, is it copied or do they refer to the same ins

[Captain Forge]

OK, so I made a certain object in one class, (lets call the object Object and the class Class1). I send a message to Class2 from Class1, and in the perameters I include Object. Does class2's and class1's instances of Object refer to the same object, or is a copy made when it is sent to class2?

More specifically (in case that wasn't clear):

I have a class titled AnalyzeInput. It makes the object Data. Data is then sent to many different classes to further analyze the data, and these classes add information to the Data class. I want to make sure all of these are referring to the same data class or if I need to get the data from each class and then addd it to the Data class. Does this make sense?

[Fubarable]

Indeed it makes sense. If you are passing a valid reference to an object, then the reference will be pointing to the same object. The best way to find out is to run tests to see what happens when an object is modified this way, is the modification detected elsewhere. Note though that if an object's state is changed in one thread, that change might not always be reflected in another thread unless the object's reference variables are marked volatile. Note to thread experts: I'm not a threading expert and am open to any and all corrections on this.

[pbrockway2]

You don't send objects to classes.

Rather loosely, a class is a recipe (blueprint/cookie-cutter) that says what type of thing an object is. Objects get created by invoking a constructor of a class. There are also so-called "factory methods", but either way you end up with a value that can be assigned to a variable:

Class1 object = new Class1();

object is a variable and it has been assigned a value. In Java that value is a reference or pointer to a newly created object whose type is Class1. Think of it as a pointer - a signpost - but one with the rather "magical" property that the pointer itself can be used to make the object do things.

Once you have assigned a variable a value which is a reference to a newly created object you can use that variable in method calls:

Class1 object = new Class1();

someObject.foo(object);
someOtherObject.bar(object);

Java is a "pass by value" language. All that means is that what gets passed is (a copy of) the value of the object variable. So objects don't get passed: reference values get passed, pointers, signposts (think of them how you will).

And they don't get passed to classes (which are types of thing), they get passed to very specific things: first an object signpost is given to whatever thing someObject references, then an object signpost is given to whatever other thing someOtherObject references. It really doesn't matter whether these two objects get the same signpost, or two different signposts. Either way they can use the signpost they are given to make whatever it is that object refers to do something.

(The usual way of speaking is to say that the method being called gets a copy of the pointer. Also people do get lazy and say objects are passed, or Strings are passed etc. That's because it's tedious to say "a (copy of) a reference to a String" etc all the time. None the less, it is important to realise that in Java you work with references not things-in-themselves.)

If it wasn't clear read the final sentence of the paragraph before last again. foo() and bar() are using the pointer (or pointers) they are passed to them to make one and the same object do things. What foo() makes the object do will be visible within the bar() method when it gets called. For instance:

// in some class
public foo(Class1 ob) {
    ob.setName("Basil");
}

// in some other class
public bar(Class1 ob) {
    System.out.println("The name of the thing a pointer to which was passed is " + ob.getName());
}

If set/getName() are implemented as you would expect and foo() and bar() called as described above then bar() will "see" the change wrought by foo(). Thereby helping to sustain the illusion that the thing itself is being passed around. And the caller of both methods will - after each has been called - "see" the accumulated changes of both.

---

To fully get the hang of the logic of references I suggest you write some code. Keep it simple to begin with and post (describing the behaviour) if you find anything counter intuiitive.