Passing by value vs. reference

[Rick Portugal]

I understand that Java passes primitives by value and objects by reference. I wrote three programs to prove it. The first two programs worked as I expected, but the third produced unexpected results.

In my first program I tested passing a primitive:

public class Test {
 
public void method1() {
int i = 100;
method2(i);
System.out.println("Final Value: " + i);
}

public void method2(int i) {
i = 200;
}

public static void main(String args[]) {
Test t = new Test();
t.method1();
}
}

It printed "Final Value: 100". That was the result I expected. Since primitives are passed by value, setting i to 200 in method2 didn't "stick".

In my second program I tested passing an object:

public class Test {
 
public void method1() {
CustomClass c = new CustomClass();
c.a = "abc";
method2(c);
System.out.println("Final Value: " + c.a);
}

public void method2(CustomClass c) {
c.a = "def";
}

public static void main(String args[]) {
Test t = new Test();
t.method1();
}
}

It printed "def". That was the result I expected. Since objects are passed by value, setting c.a to "def" did stick.

Now here's where I'm confused. In my third program I passed a String:

public class Test {
 
public void method1() {
String s = "abc";
method2(s);
System.out.println("Final Value: " + s);
}

public void method2(String s) {
s = "def";
}

public static void main(String args[]) {
Test t = new Test();
t.method1();
}
}

It printed "Final Value: abc". I was expecting it to print "def" because String is an object and objects are passed by value. Why did it print "abc"?

[marc weber]

Arguments are copies, so the "s" in each method is a local variable (each distinct from the other).
[ June 15, 2005: Message edited by: marc weber ]

[Stan James]

See if The FAQ helps!

[Steven Bell]

It's actually more correct to say Java always passes by value.

[Stuart Freeman]

Strings are immutable... they do not behave like other objects. If you want a mutable string (which will give you the behaviour you expected), have a look at the StringBuffer class.

[fred rosenberger]

Everything is pass by value. What usually trips people up is that when you have something like

MyClass myObject = new MyClass();

the myObject doesn't REALLY hold the object. it holds a REFERENCE to the object - the equivilent of an address. the actual object is stored somewhere far away. Java automatically handles finding the real object when you need it.

so, when you say "pass an object", you're really passing the reference to the object, and you do this 'pass by value'.

[Steven Bell]

Originally posted by StuartF:
Strings are immutable... they do not behave like other objects. If you want a mutable string (which will give you the behaviour you expected), have a look at the StringBuffer class.

Strings are immutable, but that has nothing to do with the confusion in the original post. I'm unaware of any behavior String has that is different from other objects.

[Rick Portugal]

Technically, you pass a reference to an object by value. In other words, Java makes a copy of the reference to an object and passes it. The point is that any changes you make to the object "sticks" because there are multiple references to the same object. You have actually changed the object - not a copy of the object. When you change the object in a method everybody outside of the method also sees the changes.

This FAQ says that "Way too many people say 'Java passes primitive by value and objects by reference'. This is not the way it should be stated." But I don't agree.

The reason people make the distinction between "passing by reference" and "passing by value" is that you need to know whether your method is changing values outside of method scope. In the case of an object it is; in the case of a primitive it isn't. The only reason anybody cares about "passing by value vs. passing by reference" is that they need to know when their changes are going to "stick". Making the further distinction that objects are not "passed by reference" but instead "passed by the value of a copy of a reference" only muddies the waters.

Arguments are copies, so the "s" in each method is a local variable (each distinct from the other)

Only if "s" is a primitive.

Strings are immutable... they do not behave like other objects. If you want a mutable string (which will give you the behaviour you expected), have a look at the StringBuffer class.

I don't understand why mutability would effect this. The fact that String is immutable means only that internally it uses a StringBuffer. But String is still an object not a primitive, isn't it?

I still don't understand why String is behaving like a primitive.

Should the rule be "Java passes primitives by value and objects by reference EXCEPT FOR STRINGS"? Are there any other objects that are like Strings that don't follow the rule?

Thanks for helping me to understand this.

[marc weber]

Originally posted by Rick Portugal:
... Only if "s" is a primitive...

No, this is also true for objects, as demonstrated by your third example in the original post.

In the second method, the variable s originally references the same String "abc" referenced by the variable s in the first method. If this were a mutable object, then it could be manipulated through either variable (i.e., the changes would "stick").

However, that's not what's happening in the second method. Instead, the variable s is simply being reassigned to reference a new String "def". But because the s in the second method is local to the method, this does not change the reference of s in the first method, and this is why your example is behaving the way it does.

[Rick Portugal]

I think I understand what you are saying. Wow. That's very subtle.

String is an object so Java did pass it by reference. But because it's immutable the method couldn't change its value, so it created a new String. That had the effect of making the change "not stick". Aye carumba.

Thanks to everyone for helping me out with that!

Let me ask you all a personal question. Be honest. Do you ever feel that Java is unnecessarily complex? I am an application developer at a bank. I don't want to have to worry about when Java will pass by value or pass by reference. I just want my programs to work. Does anyone here feel like using Java for application development is overkill?

[Steven Bell]

Actually I find Java to be refreshingly simple, once you understand how it works. It just takes time and practice like anything else.

And Java is always pass by value.

[Joel McNary]

 1: public class Test{
 2:   public int a = 10;
 3:
 4:   public static void main(String argv[]){
 5:        Test aTest = new Test();
 6:        Test.callMethod(aTest);
 7:        System.out.println("Value is: " + aTest.a);
 8:   }
 9:
10:   public static void callMethod(Test someTest){
11:       someTest.a = 20;
12:       someTest = new Test();
13:       someTest.a = 30;
14:    }
15:}

Now, what is the expected result? The problem is that there are three possibilities, but only two terms to describe them!

Pass-by-value-of-object provides the "Value is 10" result.

Pass-by-value-of-reference provides the "Value is 20" result.

Pass-by-reference provides the "Value is 30" result.

Note that Java does not pass objects; it passes references. It might help to think that while an object is a composite value, the reference is a primitive.

[Ilja Preuss]

Originally posted by Rick Portugal:
Let me ask you all a personal question. Be honest. Do you ever feel that Java is unnecessarily complex?

Yes - but not because of this issue...

I am an application developer at a bank. I don't want to have to worry about when Java will pass by value or pass by reference. I just want my programs to work.

I don't see how you could make your programs work without understanding these issues.

I see, though, how having primitives somewhat complicates the language...

Does anyone here feel like using Java for application development is overkill?

No, not at all. Just a little bit clumsy from time to time - when compared to Smalltalk, for example...

[Rick Portugal]

Originally posted by Joel McNary:

Now, what is the expected result? The problem is that there are three possibilities, but only two terms to describe them!

Pass-by-value-of-object provides the "Value is 10" result.

Pass-by-value-of-reference provides the "Value is 20" result.

Pass-by-reference provides the "Value is 30" result.

Note that Java does not pass objects; it passes references. It might help to think that while an object is a composite value, the reference is a primitive.

I don't understand what you mean. The aTest object was passed to the method by reference (or, for you purists, a copy of the aTest object was made and it was sent to the method by value). It had a member variable called "a" with the value of 10.

I don't see where anything else was passed.

[Steven Bell]

Originally posted by Rick Portugal:
a copy of the aTest object was made and it was sent to the method by value)

No, not at all. There is no copy of an object made anyware. aTest is NOT an object it is a reference. That reference was passed by value.

It may be a bit of a subtle argument, but I find it to be very important to be able to understand the language.

[Rick Portugal]

Agreed. What I meant to say was "a copy of the reference to the object was made and was sent to the method by value". Thanks for keeping me honest.

[Gauhar Khan]

hi
In java there is no concept of pass by reference as in C++...in ur third code...when u r creating s="abc" what internally is done is that a new String object is created and initialized by "abc"...when u pass this reference to a method...a copy of this reference is passed...not the actual object...so if u code s ="def" in method2() it will not change the actual object pointed by reference s...inspite a new object is created again initialize by "def"...so ur previous object remains intact...

[fred rosenberger]

I don't want to have to worry about when Java will pass by value or pass by reference. I just want my programs to work.

These two statements seem to contradict each other. On the one hand, you're saying "I don't want to understand what i need to get it to work", but on the other hand, you're saying "I want it to work".

Does anyone here feel like using Java for application development is overkill?

Depends on what you're trying to do, where your doing it, and where you need to deploy it. And, what would be your alternative choice? Believe me, C isn't any less complicated when you get into pointers and proper memory management...

[Edwin Keeton]

And which language is it that we don't have to understand in order for our programs to just work?

[Rick Portugal]

When you call a JavaScript, Korn Shell or Oracle function you don't need to stop and think "wait a minute - is this argument being passed by value or by the value of a reference, and is it possible that my changes won't take effect because one of the classes may be immutable." You just send the parameter and it works the same way each time.

Obviously you need to understand what needs to be done to get the program to work, but "understanding what needs to be done" shouldn't require a PhD. You can't create error-free systems quickly when you need to worry about a lot of subtleties and side-effects. Ideally Java would always pass parameters the same way. Maybe that means it should have no primitives. Also, I don't understand why String is immutable.

Much of programming is about reducing software complexity. Java is a great language, but it is more complicated that it needs to be.

Thanks for the help with this.

[M Beck]

Originally posted by Rick Portugal:
You can't create error-free systems quickly when you need to worry about a lot of subtleties and side-effects. Ideally Java would always pass parameters the same way. Maybe that means it should have no primitives. Also, I don't understand why String is immutable.

"good, fast, cheap: pick any two." if you know how to create error-free systems quickly under any other circumstances than someone throwing a lot of resources at that problem, you are far wiser than i.

if side-effects confuse you, there's a simple remedy i would recommend for anyone: don't use side-effects so much, write code in a more functional style. study Scheme, Lisp, O'Caml, or Haskell. quit relying on functions to modify the things you pass them as arguments unless that truly is absolutely necessary.

wherever possible, functions should take arguments that might as well be constants, return values that depend only on the arguments passed in, and do nothing else. that way it won't matter how the arguments are passed in, only what they are.

why the Java String class in particular is immutable, i do not know. it's possible that particular choice was badly made; i suspect reasonable people might disagree on the subject. immutable classes in general, though, are good things. i feel they should be more commonly used; mutating an object is inherently prone to side-effects, and immutable objects make you think more about not relying on side-effects.

[Ilja Preuss]

Originally posted by Rick Portugal:
Ideally Java would always pass parameters the same way.

Well, it does. Really.

What you need to understand is that the value of a variable *never* is an object. You *really* *really* *really* need to grok that - not just for the purpose of parameter passing.

Also, I don't understand why String is immutable.

Immutable objects are actually quite common, and can actually be used *simplify* a system. Just think of how surprising (and hard to debug) it would be if you change a String and somewhere totally unrelated a String suddenly is changed, too!

As far as I remember, Sun also did this because of security and performance considerations.

[Stuart Freeman]

Variables whether they refer to primitives or objects are always passed by value. With primitives, the value passed is a copy of the bit pattern the variable has been assigned. With objects, the value is a copy of the memory location of the object being referenced. Strings being objects are no different in this respect but they are immutable. The decision to make them so appears to have been based on performance and memory efficiency as discussed below:

From: Sun Certified Programmer & Developer for Java 2 Study Guide (Exam 310-035 & 310-027) by Kathy Sierra (Editor), Bert Bates (Editor)

One of the key goals of any good programming language is to make efficient use of memory. As applications grow, it�s very common that String literals occupy large amounts of a program�s memory, and that there is often a lot of redundancy within the universe of String literals for a program. To make Java more memory efficient, the JVM sets aside a special area of memory called the �String constant pool.� When the compiler encounters a String literal, it checks the pool to see if an identical String already exists. If a match is found, the reference to the new literal is directed to the existing String, and no new String literal object is created. (The existing String simply has an additional reference.) Now we can start to see why making String objects immutable is such a good idea. If several reference variables refer to the same String without even knowing it, it would be very bad if any of them could change the String�s value.

[Rick O'Shay]

>> Do you ever feel that Java is unnecessarily complex?

Never. Are there areas that could be simplified? Yes.

>> I am an application developer at a bank.
>> I don't want to have to worry about when Java will pass by value or pass by reference.

Agreed, you should not have to worry about that. If you find that you are you should consider a different career path � you asked for honesty. That fundamental distinction (reference or value) has significant ramifications for performance and changes how you write software dramatically. It's also a beginner's topic.

>> I just want my programs to work.
>> Does anyone here feel like using Java for application development is overkill?

Are you trying to remove noise from a digital audio stream or asses risk on an insurance application or dispense movie tickets or compute mortgage amortization tables? You have not provide and example but I think you will agree that "application development " is far too general a subtext to even attempt to answer that question.

My advice is to learn the basics of programming, perhaps through Java, so that you can determine an appropriate tool for a specific job. Java is one of the better and simpler general purpose programming languages available.

[Rick Portugal]

Originally posted by Rick O'Shay:
>> Do you ever feel that Java is unnecessarily complex?

Never. Are there areas that could be simplified? Yes.

That's a contradiction.

[Rick O'Shay]

Originally posted by Rick Portugal:
That's a contradiction.

Not really. I never find Java to be needlessly complex as a tool for building applications as was suggested. That there are specific areas where complexity could be reduced doesn't mean Java is needlessly complex. Guess it's a matter of how you interpret the question and the response.

[Alan Google]

Thanks for clearing that up.

[Jeroen Wenting]

Originally posted by Rick Portugal:

I don't understand what you mean. The aTest object was passed to the method by reference (or, for you purists, a copy of the aTest object was made and it was sent to the method by value). It had a member variable called "a" with the value of 10.

What I find very disturbing is that someone who claims to have passed SCJP and SCWCD doesn't understand that Java uses pass by value exclusively...

And people complain that employers don't value our certification, well if people with such misconceptions can get them I have to agree with those employers.

[Timmy Marks]

I'm not sure any of his certifications aren't spurious. The abbreviations did not appear on the first post in this thread, and I mean, the last one is EIEIO. Where'd you get that? Old McDonald's Farm?

If this is an unwarranted attack, please tell us what an EIEIO is and where you got it. I have googled for about an hour and every time I have seen it used, it is used to demonstrate that there are just too many abbreviations. A few examples

[Jim Yingst]

Jeez. Re: "EIEIO", an explanation can be found here.

[Ryan McGuire]

Originally posted by Jeroen Wenting:


What I find very disturbing is that someone who claims to have passed SCJP and SCWCD doesn't understand that Java uses pass by value exclusively...

Yeah but...
Passing references by value versus passing objects by reference is at most a semantic difference. I could see how someone could become a perfectly fine Java programmer/engineer/whatever and still not know or even care about the magical incantation that describes the parameter passing convention. (Edit...) As long as they how it works, what difference do the words make?

How can any language be "pass by reference" if it doesn't pass references by value?
[ June 21, 2005: Message edited by: Ryan McGuire ]

[Jeroen Wenting]

it's far from a semantic difference.
If objects were passed by reference one could change the reference to another object in a method and have that change reflected outside the method.

If (as it is) object references are passed by value this is impossible and the change in reference is local to the method.

Envision

// in some method
List aList = new ArrayList();
dosomething(aList);
System.out.println(aList(0).toString());
}
 
private void dosomething(List theList) {
  theList = new LinkedList();
  theList.add("something");
}

If objects were passed by reference this would work as the unsuspecting person expects and print "something" on the standard output.
But as object references are passed by value a NullPointerException is thrown as there is no object at position 0 in the list referenced by aList after the method call (which is an ArrayList, not the LinkedList created inside the method which is in fact lost to the garbage collector after the method completes).

[Steve Morrow]

Just to add...

Some people will say incorrectly that objects are passed "by reference." In programming language design, the term pass by reference properly means that when an argument is passed to a function, the invoked function gets a reference to the original value, not a copy of its value. If the function modifies its parameter, the value in the calling code will be changed because the argument and parameter use the same slot in memory. If the Java programming language actually had pass-by-reference parameters, there would be a way to declare halveIt so that the preceding code would modify the value of one, or so that commonName could change the variable sirius to null. This is not possible. The Java programming language does not pass objects by reference; it passes object references by value. Because two copies of the same reference refer to the same actual object, changes made through one reference variable are visible through the other. There is exactly one parameter passing mode -- pass by value -- and that helps keep things simple.

-- Arnold, K., Gosling J., Holmes D. (2000). The Java� Programming Language Third Edition. Boston: Addison-Wesley.
[ June 21, 2005: Message edited by: Steve Morrow ]

[Steve Morrow]

How can any language be "pass by reference" if it doesn't pass references by value?

I think it's important to bear in mind that passing *a* reference is not the same thing as "pass-by-reference". Pass-by-reference (not available in Java) simply means that the method gets an alias to the parameter, as opposed to a copy of it. Changes made to the variable within the method affect the value of the original argument as well. Here's an example of pass-by-reference from C#:

namespace PassingDemo
{
 
    public class PassingDemo
    {
        public static int Main()
        {
            new PassingDemo().go();
            return 0;
        }
 
        void go()
        {
            String foo = "foo";
            passByVal(foo);         // foo == "foo"
            passByRef(ref foo);     // foo == "bar"
 
            int x = 42;
            passByVal(x);           // x == 42
            passByRef(ref x);       // x == 69
        }
 
        void passByVal(String str)     { str = "bar"; }
 
        void passByRef(ref String str) { str = "bar"; }
 
        void passByVal(int i)          { i = 69; }
 
        void passByRef(ref int i)      { i = 69; }
    }
}

[Ryan McGuire]

Originally posted by Jeroen Wenting:
it's far from a semantic difference.
If objects were passed by reference one could change the reference to another object in a method and have that change reflected outside the method.

If (as it is) object references are passed by value this is impossible and the change in reference is local to the method.

No, one couldn't. In order to change a object reference to reference a different object you would need to pass the object reference by reference (i.e. an object reference reference). In general, if you want to change X, you need to pass X by reference, right? But couldn't we say that we're passing the object itself by reference? It's my contention that since the object is being passed by reference, it's the object that you can change. (e.g. arg1.height=32; )

Since we've been discussing terminology, I decided to try to look this subject up in whatever reference I just happen to have close by. On page 25 of "Java in a Nutshell, 2nd edition," [1997, O'Reilly & Associates] David Flanagan says...

Reference Data Types
The non-primitive data types in Java are objects and arrays. These non-primitive types are often called "reference types" because they are handled "by reference" -- in other words, the address of the object or array is stored in a variable, passed to methods, and so on. By comparison, primitive types are handled "by value" -- the actual primitive values are stored in variables and passed to methods.

In C, you can manipulate a value by reference by taking its address with the & operator, and you can "dereference" and address with the * and -> operators. These operators do not exist in Java: the primitive types are always passed by value; arrays and objects are always passed by reference.

I don't bring an author's words into the discussion as "proof", because A) book authors are just plain people and as prone to mistakes as anyone, and B) a book was written at a particular time and things may have changed since. However Mr. Flanagan's words echo my understanding. (Plus it shows how someone could have reached a given level and not known that Java is strictly "pass by value" and in particular Java passes object references by value but DOESN'T pass objects by reference.)

Perspective: I know how computers work and how Java works, I'm just trying to get my terminology current and standard.
[ June 21, 2005: Message edited by: Ryan McGuire ]

[Rick O'Shay]

Originally posted by Jeroen Wenting:


What I find very disturbing is that someone who claims to have passed SCJP and SCWCD doesn't understand that Java uses pass by value exclusively...

And people complain that employers don't value our certification, well if people with such misconceptions can get them I have to agree with those employers.

I would venture to say they all understand that but they interpret the passing of a reference value as "pass by reference". Practically speaking they understand what's going on.

[Rick O'Shay]

Originally posted by Alan Google:
Thanks for clearing that up.

Dear ,

Your don't think it's important to know whether something is pass by value or reference. Now you claim to be confused about the distinction between a language being needlessly complex, as you suggested, versus the language having opportunities for improvement. Not sure I can help you with that.

[Rick Portugal]

Originally posted by Rick O'Shay:
you should consider a different career path

Originally posted by Jeroen Wenting:
What I find very disturbing is that someone who claims to have passed SCJP and SCWCD doesn't understand that Java uses pass by value exclusively...

There are MANY things in life that you know that I don't. (And vice versa). So what?

Nobody was born knowing Java. As in all things that are learned, you start knowing nothing, learn a little bit at a time, until finally you reach a level of proficiency. We are all at different stages along that path. The very point of forums like this is to ask questions and learn from each other.

I meet Software Engineers all the time that don't progress in their skills because they are afraid to ask "dumb questions". They are embarrased because they feel that somehow they "should know that". The "RTFM attitude" is unbecoming and counterproductive. My advice to young engineers is don't be "that guy".

Originally posted by Rick O'Shay:
That there are specific areas where complexity could be reduced doesn't mean Java is needlessly complex.

I don't understand your position. If "there are specific areas where complexity could be reduced" doesn't that mean that "Java is needlessly complex" at least in those areas?
[ June 23, 2005: Message edited by: Jim Yingst ]

[Steve Morrow]

In general, if you want to change X, you need to pass X by reference, right? But couldn't we say that we're passing the object itself by reference?

I don't think so, as the object is not getting passed at all. It's the object's reference that is getting passed, and the object's reference is passed "by value".

However Mr. Flanagan's words echo my understanding.

Here's what Mr. Flanagan says in the Third Edition...

I've said that java handles arrays and objects "by reference." Don't confuse this with the phrase "pass by reference." "Pass by reference" is a term used to describe the method-calling conventions of some programming languages. In a pass-by-reference language, values -- even primitive values -- are not passed directly to methods. Instead, methods are always passed references to values. Thus, if the method modifies its parameters, those modifications are visible when the method returns, even for primitive types.

Java does not do this; it is a "pass by value" language. However, when a reference type is involved, the value that is passed is a reference. But this is not the same as pass-by-reference. If Java were a pass-by-reference language, when a reference type was passed to a method, it would be passed as a reference to the reference.

Flanagan, D. (1999). Java In A Nutshell. p. 74. Sebastopol, CA: O'Reilly & Associates, Inc.

And finally...

Perspective: I know how computers work and how Java works, I'm just trying to get my terminology current and standard.

For this, you can turn to none other than the creator of Java...

"Some people will say incorrectly that objects are passed "by reference." In programming language design, the term pass by reference properly means that when an argument is passed to a function, the invoked function gets a reference to the original value, not a copy of its value. If the function modifies its parameter, the value in the calling code will be changed because the argument and parameter use the same slot in memory. If the Java programming language actually had pass-by-reference parameters, there would be a way to declare halveIt so that the preceding code would modify the value of one, or so that commonName could change the variable sirius to null. This is not possible. The Java programming language does not pass objects by reference; it passes object references by value. Because two copies of the same reference refer to the same actual object, changes made through one reference variable are visible through the other. There is exactly one parameter passing mode -- pass by value -- and that helps keep things simple."

-- Arnold, K., Gosling J., Holmes D. (2000). The Java� Programming Language Third Edition. Boston: Addison-Wesley.

[Rick O'Shay]

QUOTE] I don't understand your position. If "there are specific areas where complexity could be reduced" doesn't that mean that "Java is needlessly complex" at least in those areas?[

We can agree that, had each Apollo mission dropped a morsel of green cheese on the moon, we could say the moon consisted of green cheese in those areas. I submit the Moon would not, however, be made of green cheese.

Side note, you won't hear a professional baseball player say "So what if I don't know which end of the bat to hold. Nobody knows everything and I can learn", or words to that effect.

In any event, Java is relatively uncomplicated with respect to other general purpose programming languages.