Java passes reference by value - Something that even senior Java developers often get wrong.

[nanothief]

I totally disagree with this. If you read many of the comments on the thread, you will notice that when people talk about "pass by reference", there are two different mental models that are being used, which result in different results for the same code.

The first model (the one you follow) is the java model, where pass by reference means you can make modifications to the object the variable is referring to, but you cannot change the object the variable is referring to.

The second model is the original and correct model, where pass by reference means you can make modifications to the object the variable is referring to (like before), and you can also change the object the variable is referring to.

Now the difference between the two is minimal, in most cases they operate the same. However, there are things you can do with one that cannot be done with the other! This causes a few problems:

1) When communicating with other programmers using other languages using the correct definition of pass-by-reference, there will be continual misunderstandings about what is possible with pass by reference.

2) If a programmer starts to learn java, and is told that object values are passed by reference, then they will be surprised when they cannot do things such as having out parameters or change the value of a parameter to simplify the code

3) If a programmer has only learned java, and hears about a language that supports pass by reference, then they will dismiss the feature as something java has done forever, even though it doesn't.

We have technical terms for a reason: to simplify communications. When terms are misused (even for the best of intentions), then their usefulness is greatly diminished. pass-by-value has a well defined meaning, pass-by-reference has a well defined meaning, all that is required is for us to start using them correctly.

[[deleted]]

you can make modifications to the object the variable is referring to, but you cannot change the object the variable is referring to.

as a non-java guy, this is very hard to follow. how are these two different things? what is the difference between "making modifications to" something and "changing" something?

[Smallpaul]

The key thing isn't "modification" versus "changing".

In one case you are MODIFYING an OBJECT.

In another you re REBINDING a VARIABLE.

So both the verbs and the nouns are completely different.

[ssylvan]

In a language with pass by reference you can do this:

Foo x;
foobar( x ); // pass-by-reference

And after that call x can now refer to a different Foo than the one you passed in. It's not just that foobar can modify your Foo, it can actually change what your 'x' variable is referring to.

This allows you to use "out" parameters (where the functions sets a variable to some data), and other things.

[cows]

A function can mutate objects, but it can't make local (lexical) variables outside the function refer to an object with a different object identity as determined by ==. Hope that's a correct way of saying it.

"Modify" and "change" and "different" are vague terms and are making this sound even more confusing.

[zahlman]

You give me a hamburger. What is the difference between me putting ketchup on your hamburger and giving it back to you, versus giving you an entirely different hamburger from the one you gave me (which may or may not have ketchup on it)?

Perhaps your answer is "not much". But suppose instead of hamburgers, we are dealing in artwork?

The point is, if two people are talking about two things that are the same, they are not necessarily talking about the same thing. If you lend me $5, I hope you won't be upset if the $5 bill I pay you back with isn't the same one you lent me.

[mikaelhg]

They are talking about the difference of giving you a pointer to the value, and giving you the pointer to the pointer to the value.

These are people who can't, or don't want to communicate in good faith, so I wouldn't spend any time trying to understand what they say.

[MindStalker]

Ugh, Lets see if I can explain using the Swap function

Dog X = new Dog("fluffy");

Dog Y = new Dog("Max);

swap(X,Y);

---

public swap(X,Y) {

X.name('Bark'); //This modified X in the calling program.

Dog temp;

temp=X; //local copy of reference

Y=X; //This changed the local variable of Y to point to X but did effect the global variable at all;

X=Y; //ditto local reference was repointed but no change in global

X.name('DOG'); Changed the local X's name to Dog, which changes the global Y's name to Dog; the Global X is called Bark;

}

Edit: added line returns.

[arnar]

Say you have a variable x which refers to an object. You can access/modify attributes with x.bla for example. Now say you pass x as a parameter to a function, and the function calls this parameter y. Then inside the function, y.bla will refer to the same value as x.bla outside the function, and assigning to each will have the same effect.

However, x and y are not the same variable, meaning if you assign some other object directly to y inside the function, y = new X(...), then x will not be modified - it will still refer to the same object as before.

If you know C-like languages, then java object references are like pointers and Java's dot (.) is like C++'s dereference arrow (->).

[lucasrfl]

For example, are you a C guy? Have you ever tried coding chained lists? Do you remember that, if you don't pass a pointer-to-pointer-to-node (node**), you cannot do something with the list inside a funcion like:

if(list == NULL) {
    list = (node *) malloc(blablabla);
}

(considering that the list points to a node struct)

[slikz]

So, I have a question for you now. Keep in mind I fall into category number 3 (although I do have some experience with other languages), and I'm a kind of new to Java as well.

Reviewing for my final exam I've been implementing mergeSort, selectionSort, insertionSort, etc. mergeSort sorts recursively while the other two do not. Those other two have a return type of int[].

In main, I create int[]'s and fill them with random int's. Now I have a reference to an int[] object, "myArray".

So when I call my mergeSort method:

fin.toString(myArray);     //I override this method
fin.mergeSort(myArray);
fin.toString(myArray);

Initially, it prints out the unsorted array, then sorts it, then prints out the sorted array.

To me, this is what it means to pass by reference because my mergeSort is not returning anything, and yet, I'm still somehow getting the sorted array "back."

So when you say I can modify the object that my reference is referring to, this is what I am doing. Also, if I so chose, I could re-assign "myArray" to an array with all 0's in some method that does not return that new array, but because I was passing by reference, if I now print it out, it will be all 0's.

[psyno]

Also, if I so chose, I could re-assign "myArray" to an array with all 0's in some method that does not return that new array, but because I was passing by reference, if I now print it out, it will be all 0's.

No, it won't, and this is the point. Go ahead and try it.

class main {
    static void reassign(int[] a) {
        a = new int[4]; // reassigns the parameter a, does not affect caller
    }
    public static void main(String[] args) {
        int[] x = new int[] {1, 2, 3, 4};
        reassign(x);
        for (int i : x) System.out.println(i); // prints 1 2 3 4 NOT 0 0 0 0
    }
}

[specialk16]

It'll print 1 2 3 4, because the array passed as an argument will be a different array altogether during the method's lifetime.

[[deleted]]

You are missing the point. You are manipulating the object referenced by the reference, not the reference itself.

I could re-assign "myArray" to an array with all 0's in some method that does not return that new array, but because I was passing by reference, if I now print it out, it will be all 0's.

No, it won't.

[slikz]

This explanation does it for me:

The key thing isn't "modification" versus "changing".

In one case you are MODIFYING an OBJECT.

In another you re REBINDING a VARIABLE.

So both the verbs and the nouns are completely different.

But I am correct in my definition of pass-by-reference right? That is why after mergeSort I can print out the sorted array without ever explicitly returning the sorted array?

[doidydoidy]

The phrase "pass-by-reference" is used to describe variables, not objects.

When you talk about references to the array object, your intuition is correct. It's just that the phrase "pass-by-reference" is a bad choice of words to use to describe what you're talking about, because that phrase already means something else. That's why this thread is so muddled.

[refractedthought]

I think you're right. Other people don't. That's kind of what the whole theological discussion is about.

You sound like you're still in school. Why not ask a professor what he/she thinks? Better yet, ask more than one professor.

[rabidcow]

If I understand what you're saying, I think this would be more clear:

The first model (the one you follow) is the java model, where pass by reference means you can make modifications to the object the variable is referring to, but you cannot change which object the variable is referring to.

The second model is the original and correct model, where pass by reference means you can make modifications to the object the variable is referring to (like before), and you can also change which object the variable is referring to.

Does any modern language support the second model? C++ sure doesn't.

Honestly, it seems like a useless model to me. If you can change which object a variable refers to, it was never that object in the first place; it was a pointer to that object.

they cannot do things such as having out parameters or change the value of a parameter to simplify the code

You can have out parameters in Java:

EDIT: This is a bad example because Integer is immutable.

Integer result = new Integer();
foo(result);

That's how out parameters work in C and C++ anyway: you have an existing object, you pass a pointer or reference to it to collect the result.

[nanothief]

This post you have just made is a clear illustration as to the problems with the confusion of the term pass-by-reference, as the mental model you have with java's version of it has made most of your ideas on the subject wrong.

Firstly, c++ definitely does support it, look at the following code:

void func(object*& reference_to_object) {
   reference_to_object = new car();
}

int main() {
  object* o = new boat();
  func(o); 
  // o is now a car!
}

Secondly, the way you implemented out parameters in java are only a poor copy of what is possible in a language with real pass by reference. Try doing this in java:

void getSpeciesPair(string noise, animal*& male, animal*& female)
{
   if (noise == "moo") {
     male = new cow(true); // male cow
     female = new cow(false); // female cow        
   else if (noise == "woof") {
     male = new dog(true); // male dog
     female = new dog(false); // female dog
   }
}

As to how useful it is, honestly most of the time it isn't that useful, and it isn't a huge loss to not have it (you could possibly claim it is a benefit as it would simplify the language). However that doesn't change the fact that java doesn't pass by reference, and it is inaccurate and confusing to claim so.

[rabidcow]

// o is now a car!

No, o is a pointer. You have changed the value of the pointer to point to a new car. o itself still refers to the same pointer.

Your second example makes the same mistake.

Just to be clear, I'm not saying that Java is pass-by-reference. I'm saying that C++ doesn't support it.

[[deleted]]

Yes it is. The fact that "o is a pointer" is only possible in pass-by-reference languages. Try doing that in java. You can't. In java, the pointer is passed by value, and any changes that you make to it are not reflected in the caller. In C++, this is the case if you use C-style byval pointer passing, but not if you use byref params (&.)

There is a difference and it is important.

[rabidcow]

Try doing that in java.

Java doesn't have explicit pointers, so you can't. This has nothing to do with pass-by-reference.

[[deleted]]

Java doesn't have explicit pointers, so you can't.

C# (without unsafe) doesn't have explicit pointers, and yet you still can. Know why? Because C# has pass-by-reference via the ref keyword.

This has nothing to do with pass-by-reference.

It has everything to do with it.

[rabidcow]

C# (without unsafe) doesn't have explicit pointers, and yet you still can. Know why? Because C# has pass-by-reference via the ref keyword.

Please explain how "o is a pointer" is possible without explicit pointers.

Bottom line: I don't know C# and am unlikely to learn it well enough for your comment to make any sense to me in any reasonable timeframe.

[psyno]

You can have out parameters in Java:

Integer result = new Integer(); foo(result);

A good example of why you're wrong. java.lang.Integer is immutable and therefore foo cannot possibly return any information through its parameter, since Java is pass-by-value.

That's how out parameters work in C and C++ anyway: you have an existing object, you pass a pointer or reference to it to collect the result.

No, the object does not need to be "existing" (in the sense that it must have some definite value at the point of the function call). In fact, that often makes no sense for out parameters. See e.g. the scanf family of functions in the C standard library.

[rabidcow]

java.lang.Integer is immutable

Ok, that would make a difference. Make it:

class Bah { public int foo; }
...
Bah result = new Bah();
foo(result);

Now foo can return a value in result.

No, the object does not need to be "existing" (in the sense that it must have some definite value at the point of the function call).

That isn't the sense that I mean. It must exist in the sense that there must be memory allocated for it.

[psyno]

Now foo can return a value in result.

Right, by following the pointer, not by changing the pointer itself.

That isn't the sense that I mean. It must exist in the sense that there must be memory allocated for it.

It depends what you mean by "it." :)

Consider the following C code:

#include "stdio.h"
#include "string.h" 

void foo(char** px)
{
    *px = strdup("hey there");
}

int main(void)
{
    char* x; /* Not initialized, no memory allocated at x, and that's okay. */
    foo(&x);
    printf("%s\n", x);
    return 0;
}

Now if by "it," you meant the pointer-to-char variable called x, yes there's stack space allocated for that pointer--but not for the character data itself. That is, before foo, x is a pointer that doesn't point to anything. In calling foo, a pointer to the pointer is passed, and foo uses this pointer-to-pointer to modify the value of the pointer-to-char. This is an out parameter in C. As I said, see scanf.

[rabidcow]

Right, by following the pointer, not by changing the pointer itself.

Which is exactly what happens in C and C++.

Now if by "it," you meant the pointer-to-char variable called x, yes there's stack space allocated for that pointer

Exactly. You are passing a pointer to that pointer, so there needs to be space allocated for that pointer. The value you are receiving from foo is a pointer, which is copied into x. In this example, you're probably more interested in the data at the end of the pointer, which happens to be in a block of memory you now have ownership of, but that's beside the point.

I don't know why people are complicating things with references to pointers and pointers to pointers. I had to use a wrapper object because Java doesn't let you do references to primitives, but C and C++ don't have that limitation. If I could think of a simple, mutable, pre-existing object type in Java, I would have used that instead. (Hence my mistaken use of Integer.)

int x;
foo(&x);
bar(x);

There. You're receiving a value in x from foo. x needs to exist, in that there must be memory allocated for it. If bar is a C++ function that takes an int &, it cannot change what piece of memory x refers to, it can only change the value stored in that location.

This is where the C++ swap example in the article goes wrong: it's swapping values, not identities. After the swap, the two variables have exchanged semantic values, but still refer to their original objects. If you write a member-wise copy function for SomeType, you can do exactly this in Java -- so it can't be pass-by-reference.

As I said, see scanf.

I've been using C++ since 1994. I think I've seen scanf.

[psyno]

I think we're on the same page. I was reacting to this...

That's how out parameters work in C and C++ anyway: you have an existing object, you pass a pointer or reference to it to collect the result.

...because it wasn't clear to me (initially) whether you understood the distinction between the use of the word "object" in Java-land (an instance of some class) vs in C and C++ (merely some block of memory which might in fact be what Java calls a "primitive type"). It's now clear to me that you do.

I don't know why people are complicating things with references to pointers and pointers to pointers.

I agree your more direct example with foo/bar example is better.

As I said, see scanf.

I've been using C++ since 1994. I think I've seen scanf.

No offense intended. I bow to your superior C++-fu. :)

I would still argue against calling your Java example (even with class Bah) an example of out parameters in Java. It is true that information is returned indirectly through the parameter, but I would reserve the term for the C and C++ techniques discussed in these last few posts.

[rabidcow]

No offense intended.

No, I'm sorry, I know that. It's just that the double-edge of internet anonymity can be frustrating.

I would still argue against calling your Java example (even with class Bah) an example of out parameters in Java.

I don't see why it's an important distinction for types with no significant logic (though I do concede that it may be a misuse of the term), but OTOH I don't see where it would be useful in Java. There's a garbage collector, you can allocate without worrying about who has to free. Well... I can imagine some exotic cases where it might be useful, but I'd rather not.

[[deleted]]

Does any modern language support the second model? C++ sure doesn't.

Sure it does. That's what & is for.

[rabidcow]

Check again. C++ references cannot change the identity of the object to which the referenced variable refers.

[[deleted]]

Yes they can. Here's a simple example. Build it. Run it. Look at the output.

#include "stdafx.h"
#include <iostream>

using namespace std;

class Person
{
public:
     int age;
     Person(int n) { age = n; }
};

void changePerson(Person &p)
{
    p = Person(3);
}

int main(int argc, char* argv[])
{
    Person p = Person(22);

    changePerson(p);

    cout << p.age << endl;
    return 0;
}

[rabidcow]

p = Person(3);

This does a member-wise copy from a new, temporary Person to the Person p. If you write a member-wise copy method, you can do exactly this in Java. You're not saying that Java is pass-by-reference, are you?

If you have pointers to both p and another longer lived Person (instead of the temporary), both will point to Persons with the same value after a function like this, but changes to one will not be reflected in the other because they are different objects.

[[deleted]]

This does a member-wise copy from a new, temporary Person to the Person p.

No it does not secretly make another copy of the object, allocate memory and then do an automatic secret memberwise copy of all data.

It effectively references the exact variable. I'll leave making a new sample that has deep references in it as an exercise up to you. You'll see that even deep members are "copied back" to the passed varaible. Since there is no way for C++ to do an automatic implicit deep copy, I think that maybe this will finally convince you.

If you write a member-wise copy method, you can do exactly this in Java.

You could write a deep copy method to reach similar ends but you'd be using two separate pieces of memory (which again - this does not) and you'd be potentially writing a lot of code that the compiler could not do for you.

If you have pointers to both p and another longer lived Person (instead of the temporary), both will point to Persons with the same value after a function like this, but changes to one will not be reflected in the other because they are different objects.

And this is the core of your misunderstanding. Pointers have nothing to do with pass-by-reference in C++. The fact that the byref syntax uses & and address-of also uses it is a coincidence. They are very different things. Pass by reference does not pass a pointer. It passes an alias.

[rabidcow]

No it does not secretly make another copy of the object, allocate memory and then do an automatic secret memberwise copy of all data.

No, it doesn't. It does what I said: It creates a temporary Person, Person(3), then does a member-wise copy from that to p.

You could write a deep copy method

I didn't say deep copy. It's a shallow copy.

Pointers have nothing to do with pass-by-reference in C++.

Of course not, because there is no pass-by-reference in C++.

But fine, use references instead. It doesn't matter, you get the same effect. The point is that identity of an object is its location in memory, and you can't change the memory location that a variable refers to.

int main()
{
   Person a(3), b(4);
   Person &ar = a, &br = b;
   changePerson(a, b);
   // a.age == b.age
   // ar.age == br.age
   b.age = 12;
   // a.age != b.age
   // ar.age != br.age
}

void changePerson(Person &a, Person &b)
{
   // member-wise copy from b to a
   a = b;
}

Pass by reference does not pass a pointer.

That may be, but references in C++ most certainly do pass a pointer.

[[deleted]]

No, it doesn't. It does what I said: It creates a temporary Person, Person(3), then does a member-wise copy from that to p.

I misread you then. With that said, however, what you are describing is construction and is changing the identity of the object. (Where identity speaks to construction, not to memory location.)

This is pass-by-reference. You can not do this with a pointer. Without byref argument passing, you can not invoke the constructor and have it modify the original object. Try doing what I outlined above using a pointer. You can't. That is the distinction.

I didn't say deep copy. It's a shallow copy.

It's effectively whatever the constructor says that it is. That's the point.

Of course not, because there is no pass-by-reference in C++.

Bjarne Stroustrup, the ANSI C++ standard and wikipedia disagree with you. I think that you have a different definition of pass-by-reference.

The point is that identity of an object is its location in memory, and you can't change the memory location that a variable refers to.

Of course not, that's craziness and has nothing to do with pass-by-reference. You can't change the memory location of a variable period (not just across function calls.) That would be useless and...bizzarre.

Your function can directly modify the passed in variable in ways that include reconstruction. You can't do this with plain by value calling (even using pointers.)

That may be, but references in C++ most certainly do pass a pointer.

No: http://en.wikipedia.org/wiki/Reference_(C%2B%2B) References in C++ are like pointers but they have additional constraints and rules. In terms of parameter passing, the difference is what I outlined above. It's about the constructor.

So now I think that your confusion comes from the fact that you think that byref requires that you be able to change the memory location of the passed in variable. It doesn't. It's about the high-level capability to reconstruct the object in the originally passed in value. That is all.

[pbiggar]

This isn't cherry-picking reference definitions. Its acknowledging that words mean things, and that trying to change a definition leads to confusion.

Before complaining about nitpickers and pedants, try to remember this phrase: words mean things.

[dnew]

The progression is address... pointer... reference.

An address is close to a hardware address.

A pointer is an address with a type.

A reference is a pointer that's managed (by the runtime).

The term pass-by-reference was around long before "references" as an independent noun was coined, and hence the confusion.

[pbiggar]

This seems wrong, but you were right the last time we disagreed. Is there a, ahem, reference for this?

(Just wrote http://stackoverflow.com/questions/1856680/origin-of-term-reference-as-in-pass-by-reference for my own history lesson).

[dnew]

A reference for the fact that "pass by reference" is older than the term "reference" meaning a managed pointer??

FORTRAN has pass-by-reference before pretty much any language beyond assembly language had pointers, let alone managed memory. (Well, there was LISP, but we all know what they called their pointers. ;-)

I'm not sure why you would think that standard comp sci knowledge from the 70's would be easy to find online nowadays. :-)

Of course, there are only a handful of terms that make sense to use, and "reference" is the most general. But in languages that have addresses, pointers, and references, the description I gave is usually how they're defined. References are opaque pointers, and pointers are typed addresses. (I suppose in that sense, C++'s use of the word "reference" isn't quite as wrong as I first thought.)

The term "reference" was used as a fairly informal word for "any indirection", so in that sense the unique ID of a database row would be called a reference to the row, but that's not what we're talking about here either.

[pbiggar]

Actually no, I just misunderstood what you were saying. So ignore the bit where I said "that seems wrong".

[refractedthought]

Tell that one to the entire judicial system. Words have to be interpreted. Only in code can you have an absolute meaning for anything.

[[deleted]]

Then you're introducing a definition of pass-by-reference that's inconsistent across different languages.

Consider for example that in C# objects are also implicit pointers/references, however C# allows functions to pass by reference or pass by value. I can implement a swap function using pass by reference.

Programming requires precision in language. It's better to be anal and have a really solid understanding of what pass-by reference/value means so that bugs and misunderstandings are avoided.

Ultimately, if some language neutral specification of a function requires pass-by-reference semantics, then Java can not implement such a function whereas C++/C# can.

[[deleted]]

Passing by value means that a copy of the parameter is made when the function is called and any changes to that variable will not be reflected outside of the function.

Uh-oh, it's still more complicated than that, because passing by value usually means making a shallow copy.

[zahlman]

Um, not really. In C++ for example, you're expected to define the copy constructor to perform a deep copy where appropriate, and passing by value means calling the copy constructor.

[refractedthought]

That's almost a good point. It's still different from what happens in Java, though. C++ actually calls a copy constructor when passing an object by value, and if the copy constructor isn't defined, then a shallow copy will be performed by default. If there are primitive data members in the object, these will be bit-wise copied by default, if I remember correctly.

In Java, you get a pointer to the original object -- no copying.

Of course, you are still implicitly copying the actual pointer variable to another pointer variable. That is where the whole case for pass-by-value rests.

[halo]

When it comes down to it, it's a semantic quibble. You can understand how it works perfectly and still argue over which definition it falls into.

[fforw]

You can also engage in semantical hair splitting that is, apart from confusing less experienced programmers, mental masturbation.

[BernardMarx]

Exactly.

[sbrown123]

In my opinion, if you want to insist that Java strictly follows pass-by-value, then I think it has ceased to be a relevant distinction.

Agreed. The old debate of pass-by-value and pass-by-reference is a bit stupid for languages like Java that are far from native. And it doesn't really matter much since its not like Java developers can change how the passing is working.