This site uses cookies to deliver our services and to show you relevant ads and job listings.
By using our site, you acknowledge that you have read and understand our Cookie Policy, Privacy Policy, and our Terms of Service.
Your use of Stack Overflow’s Products and Services, including the Stack Overflow Network, is subject to these policies and terms.

Join us in building a kind, collaborative learning community via our updated
Code of Conduct.

I believe that much of the confusion on this issue has to do with the fact that different people have different definitions of the term "reference". People coming from a C++ background assume that "reference" must mean what it meant in C++, people from a C background assume "reference" must be the same as "pointer" in their language, and so on. Whether it's correct to say that Java passes by reference really depends on what's meant by "reference".
– GravityJul 30 '11 at 7:23

96

I try to consistently use the terminology found at the Evaluation Strategy article. It should be noted that, even though the article points out the terms vary greatly by community, it stresses that the semantics for call-by-value and call-by-reference differ in a very crucial way. (Personally I prefer to use call-by-object-sharing these days over call-by-value[-of-the-reference], as this describes the semantics at a high-level and does not create a conflict with call-by-value, which is the underlying implementation.)
– user166390Dec 15 '11 at 6:12

47

@Gravity: Can you go and put your comment on a HUGE billboard or something? That's the whole issue in a nutshell. And it shows that this whole thing is semantics. If we don't agree on the base definition of a reference, then we won't agree on the answer to this question :)
– MadConanNov 12 '13 at 20:58

22

I think the confusion is "pass by reference" versus "reference semantics". Java is pass-by-value with reference semantics.
– spraffMar 27 '14 at 13:54

8

@Gravity, while you're absolutely correct in that folks coming from C++ will instinctively have a different intuition set regarding the term "reference", I personally believe the body is more buried in the "by". "Pass by" is confusing in that it is absolutely distinct from "Passing a" in Java. In C++, however it colloquially is not. In C++ you can say "passing a reference", and it's understood that it will pass the swap(x,y) test.
– user4229245Mar 23 '15 at 13:44

78 Answers
78

Java is always pass-by-value. Unfortunately, they decided to call the location of an object a "reference". When we pass the value of an object, we are passing the reference to it. This is confusing to beginners.

In the example above aDog.getName() will still return "Max". The value aDog within main is not changed in the function foo with the Dog"Fifi" as the object reference is passed by value. If it were passed by reference, then the aDog.getName() in main would return "Fifi" after the call to foo.

Likewise:

public static void main(String[] args) {
Dog aDog = new Dog("Max");
foo(aDog);
// when foo(...) returns, the name of the dog has been changed to "Fifi"
aDog.getName().equals("Fifi"); // true
}
public static void foo(Dog d) {
d.getName().equals("Max"); // true
// this changes the name of d to be "Fifi"
d.setName("Fifi");
}

In the above example, Fifi is the dog's name after call to foo(aDog) because the object's name was set inside of foo(...). Any operations that foo performs on d are such that, for all practical purposes, they are performed on aDog itself (except when d is changed to point to a different Dog instance like d = new Dog("Boxer")).

Isn't it slightly confusing the issue with internal details? There's no conceptual difference between 'passing a reference' and 'passing the value of a reference', assuming that you mean 'the value of the internal pointer to the object'.
– izbSep 8 '08 at 14:58

326

But there is a subtle difference. Look at the first example. If it was purely pass by reference, aDog.name would be "Fifi". It isn't - the reference you are getting is a value reference that if overwritten will be restored when exiting the function.
– erlandoSep 11 '08 at 6:55

260

@Lorenzo: No, in Java everything is passed by value. Primitives are passed by value, and object references are passed by value. The objects themselves are never passed to a method, but the objects are always in the heap and only a reference to the object is passed to the method.
– Esko LuontolaFeb 12 '09 at 23:02

250

My attempt at a good way to visualize object passing: Imagine a balloon. Calling a fxn is like tieing a second string to the balloon and handing the line to the fxn. parameter = new Balloon() will cut that string and create a new balloon (but this has no effect on the original balloon). parameter.pop() will still pop it though because it follows the string to the same, original balloon. Java is pass by value, but the value passed is not deep, it is at the highest level, i.e. a primitive or a pointer. Don't confuse that with a deep pass-by-value where the object is entirely cloned and passed.
– dhacknerOct 20 '10 at 16:38

119

What's confusing is that object references are actually pointers. In the beginning SUN called them pointers. Then marketing informed that "pointer" was a bad word. But you still see the "correct" nomenclature in NullPointerException.
– Prof. FalkenFeb 9 '11 at 9:46

someDog is followed to the Dog it points to (the Dog object at address 42)

that Dog (the one at address 42) is asked to change his name to Max

at line "BBB"

a new Dog is created. Let's say he's at address 74

we assign the parameter someDog to 74

at line "CCC"

someDog is followed to the Dog it points to (the Dog object at address 74)

that Dog (the one at address 74) is asked to change his name to Rowlf

then, we return

Now let's think about what happens outside the method:

Did myDog change?

There's the key.

Keeping in mind that myDog is a pointer, and not an actual Dog, the answer is NO. myDog still has the value 42; it's still pointing to the original Dog (but note that because of line "AAA", its name is now "Max" - still the same Dog; myDog's value has not changed.)

It's perfectly valid to follow an address and change what's at the end of it; that does not change the variable, however.

Java works exactly like C. You can assign a pointer, pass the pointer to a method, follow the pointer in the method and change the data that was pointed to. However, you cannot change where that pointer points.

In C++, Ada, Pascal and other languages that support pass-by-reference, you can actually change the variable that was passed.

If Java had pass-by-reference semantics, the foo method we defined above would have changed where myDog was pointing when it assigned someDog on line BBB.

Think of reference parameters as being aliases for the variable passed in. When that alias is assigned, so is the variable that was passed in.

This is why the common refrain "Java doesn't have pointers" is so misleading.
– BeskaApr 2 '09 at 17:52

121

You are wrong, imho. "Keeping in mind that myDog is a pointer, and not an actual Dog, the answer is NO. myDog still has the value 42; it's still pointing to the original Dog." myDog has value 42 but its name argument now contains "Max", rather than "Rover" on // AAA line.
– ÖzgürApr 6 '09 at 5:22

163

Think about it this way. Someone has the address of Ann Arbor, MI (my hometown, GO BLUE!) on a slip of paper called "annArborLocation". You copy it down on a piece of paper called "myDestination". You can drive to "myDestination" and plant a tree. You may have changed something about the city at that location, but it doesn't change the LAT/LON that was written on either paper. You can change the LAT/LON on "myDestination" but it doesn't change "annArborLocation". Does that help?
– Scott StanchfieldApr 23 '09 at 13:06

33

@Scott Stanchfield: I read your article about a year ago and it really helped clear things up for me. Thanks! May I humbly suggest a little addition: you should mention that there is actually a specific term that describes this form of "call by value where the value is a reference" that was invented by Barbara Liskov for describing the evaluation strategy of her CLU language in 1974, in order to avoid confusion such as the one your article addresses: call by sharing (sometimes called call by object-sharing or simply call by object), which pretty much perfectly describes the semantics.
– Jörg W MittagSep 7 '10 at 22:12

22

@Gevorg - The C/C++ languages don't own the concept of a "pointer". There are other languages that use pointers but do not allow the same types of manipulation of pointers that C/C++ allow. Java has pointers; they're just protected against mischief.
– Scott StanchfieldDec 30 '11 at 18:30

+1 Nice stuff. good diagrams. I also found a nice succinct page here adp-gmbh.ch/php/pass_by_reference.html OK I admit it is written in PHP, but it is the priciple of understanding the difference that I think is important (and how to manipulate that difference to your needs).
– DaveMJun 7 '13 at 8:46

3

@Eng.Fouad It's a nice explanation but if a points to the same object as f (and never gets its own copy of the object f points to), any changes to the object made using a should modify f aswell (since they are both working with the same object), so at some point a must get its own copy of the object f points to.
– Mr DJul 15 '13 at 19:08

10

@MrD when 'a' points to the same object 'f' also points to, then any change made to that object via 'a' is also observable via 'f', BUT IT DID NOT CHANGE 'f'. 'f' still points to the same object. You can totally change the object, but you can never change what 'f' points to. This is the fundamental issue that for some reason some people just can't comprehend.
– Mike BraunDec 1 '13 at 13:02

@MikeBraun ...what? Now you've confused me :S. Isn't what you just wrote contrary to what 6. and 7. shows?
– Evil Washing MachineNov 18 '14 at 11:34

4

This is the best explanation I've found. By the way, what about the basic situation? For example, the argument requires an int type, does it still pass the copy of an int variable to the argument?
– allenwangMay 21 '16 at 12:38

This will give you some insights of how Java really works to the point that in your next discussion about Java passing by reference or passing by value you'll just smile :-)

Step one please erase from your mind that word that starts with 'p' "_ _ _ _ _ _ _", especially if you come from other programming languages. Java and 'p' cannot be written in the same book, forum, or even txt.

Step two remember that when you pass an Object into a method you're passing the Object reference and not the Object itself.

Student: Master, does this mean that Java is pass-by-reference?

Master: Grasshopper, No.

Now think of what an Object's reference/variable does/is:

A variable holds the bits that tell the JVM how to get to the referenced Object in memory (Heap).

When passing arguments to a method you ARE NOT passing the reference variable, but a copy of the bits in the reference variable. Something like this: 3bad086a. 3bad086a represents a way to get to the passed object.

So you're just passing 3bad086a that it's the value of the reference.

You're passing the value of the reference and not the reference itself (and not the object).

The variable person is created in line #1 and it's null at the beginning.

A new Person Object is created in line #2, stored in memory, and the variable person is given the reference to the Person object. That is, its address. Let's say 3bad086a.

The variable person holding the address of the Object is passed to the function in line #3.

In line #4 you can listen to the sound of silence

Check the comment on line #5

A method local variable -anotherReferenceToTheSamePersonObject- is created and then comes the magic in line #6:

The variable/reference person is copied bit-by-bit and passed to anotherReferenceToTheSamePersonObject inside the function.

No new instances of Person are created.

Both "person" and "anotherReferenceToTheSamePersonObject" hold the same value of 3bad086a.

Don't try this but person==anotherReferenceToTheSamePersonObject would be true.

Both variables have IDENTICAL COPIES of the reference and they both refer to the same Person Object, the SAME Object on the Heap and NOT A COPY.

A picture is worth a thousand words:

Note that the anotherReferenceToTheSamePersonObject arrows is directed towards the Object and not towards the variable person!

If you didn't get it then just trust me and remember that it's better to say that Java is pass by value. Well, pass by reference value. Oh well, even better is pass-by-copy-of-the-variable-value! ;)

Now feel free to hate me but note that given this there is no difference between passing primitive data types and Objects when talking about method arguments.

You always pass a copy of the bits of the value of the reference!

If it's a primitive data type these bits will contain the value of the primitive data type itself.

If it's an Object the bits will contain the value of the address that tells the JVM how to get to the Object.

Java is pass-by-value because inside a method you can modify the referenced Object as much as you want but no matter how hard you try you'll never be able to modify the passed variable that will keep referencing (not p _ _ _ _ _ _ _) the same Object no matter what!

The changeName function above will never be able to modify the actual content (the bit values) of the passed reference. In other word changeName cannot make Person person refer to another Object.

Of course you can cut it short and just say that Java is pass-by-value!

Do you mean pointers?.. If I get it correctly, in public void foo(Car car){ ... }, car is local to foo and it contains the heap location of the Object? So if I change car's value by car = new Car(), it will point to different Object on the heap? and if I change car's property valu by car.Color = "Red", the Object in the heap pointed by car will be modified. Also, it is the same in C#? Please reply! Thanks!
– dppFeb 25 '12 at 3:29

8

@domanokz You're killing me, please don't say that word again! ;) Note that I could have answered this question without saying 'reference' as well. It's a terminology issue and 'p's make it worse. Me and Scot have different views on this unfortunately. I think you got how it works in Java, now you can call it pass by-value, by-object-sharing, by-copy-of-the-variable-value, or feel free to come up with something else! I don't really care as long as you got how it works and what's in a variable of type Object: just a PO Box address! ;)
– GevorgFeb 25 '12 at 21:25

7

Sounds like you just passed a reference? I'm going to championing the fact that Java is still a copied pass-by-reference language. The fact that it is a copied reference doesn't change the terminology. Both the REFERENCES still point to the same object. This is a purist's argument...
– John StricklerMar 12 '14 at 17:38

2

I guess Java designed with pointers in mind. Otherwise, why NullPointerException exists? Nevertheless, for this wonderful explanantion, getting pointers will just make it complicated
– brain stormAug 20 '14 at 17:42

2

So drop in on theoretical line #9 System.out.println(person.getName()); what will show up? "Tom" or "Jerry"? This is the last thing that will help me hurdle this confusion.
– TheBrennyOct 19 '14 at 12:20

So how is it that anyone can be at all confused by this, and believe that Java is pass by reference, or think they have an example of Java acting as pass by reference? The key point is that Java never provides direct access to the values of objects themselves, in any circumstances. The only access to objects is through a reference to that object. Because Java objects are always accessed through a reference, rather than directly, it is common to talk about fields and variables and method arguments as being objects, when pedantically they are only references to objects. The confusion stems from this (strictly speaking, incorrect) change in nomenclature.

So, when calling a method

For primitive arguments (int, long, etc.), the pass by value is the actual value of the primitive (for example, 3).

For objects, the pass by value is the value of the reference to the object.

So if you have doSomething(foo) and public void doSomething(Foo foo) { .. } the two Foos have copied references that point to the same objects.

Naturally, passing by value a reference to an object looks very much like (and is indistinguishable in practice from) passing an object by reference.

Since the values of the primitives are immutable (like String), the difference between the two cases is not really relevant.
– Paŭlo EbermannFeb 3 '11 at 1:23

4

Exactly. For all you can tell via observable JVM behavior, primitives could be being passed by reference and could live on the heap. They don't, but that's not actually observable in any way.
– GravityJul 31 '11 at 4:50

5

primitives are immutable? is that new in Java 7?
– Carlos HeubergerAug 22 '11 at 11:26

2

@CarlosHeuberger, "primitives are immutable?". The point is that you can pretend that 'primitives' are actually (mutable) references to immutable objects.
– Aaron McDaidJul 30 '15 at 16:29

4

Pointers are immutable, primitives in general are mutable. String is also not a primitive, it is an object. Moreover, the underlying structure of the String is a mutable array. The only immutable thing about it is the length, that being the inherent nature of arrays.
– kingfrito_5005Aug 12 '15 at 18:44

But the thing that keeps getting repeated "you can't change the value of objects passed in arguments" is clearly false. You may not be able to make them refer to a different object, but you can change their contents by calling their methods. IMO this means you lose all the benefits of references, and gain no additional guarantees.
– TimmmmJul 24 '11 at 19:13

31

I never said "you can't change the value of objects passed in arguments". I will say "You can't change the value of the object reference passed in as a method argument", which is a true statement about the Java language. Obviously you can change the state of the object (as long as it's not immutable).
– ScArcher2Aug 1 '11 at 14:19

16

Keep in mind that you cannot actually pass objects in java; the objects stay on the heap. Pointers to the objects can be passed (which get copied onto the stack frame for the called method). So you never change the passed-in value (the pointer), but you're free to follow it and change the thing on the heap to which it points. That's pass-by-value.
– Scott StanchfieldJan 26 '12 at 22:17

5

Sounds like you just passed a reference? I'm going to championing the fact that Java is still a copied pass-by-reference language. The fact that it is a copied reference doesn't change the terminology. Both the REFERENCES still point to the same object. This is a purist's argument...
– John StricklerMar 12 '14 at 17:38

2

Java does not pass an object, it passes the value of the pointer to the object. This creates a new pointer to that memory location of the original object in a new variable. If you change the value (the memory address it points to) of this pointer variable in a method, then the original pointer used in the method caller remains unmodified. If you are calling the parameter a reference then the fact that it is a copy of the original reference, not the original reference itself such that there are now two references to the object means that it is pass-by-value
– theferrit32Nov 19 '14 at 16:38

I feel like arguing about "pass-by-reference vs pass-by-value" is not super-helpful.

If you say, "Java is pass-by-whatever (reference/value)", in either case, you're not provide a complete answer. Here's some additional information that will hopefully aid in understanding what's happening in memory.

Crash course on stack/heap before we get to the Java implementation:
Values go on and off the stack in a nice orderly fashion, like a stack of plates at a cafeteria.
Memory in the heap (also known as dynamic memory) is haphazard and disorganized. The JVM just finds space wherever it can, and frees it up as the variables that use it are no longer needed.

Okay. First off, local primitives go on the stack. So this code:

int x = 3;
float y = 101.1f;
boolean amIAwesome = true;

results in this:

When you declare and instantiate an object. The actual object goes on the heap. What goes on the stack? The address of the object on the heap. C++ programmers would call this a pointer, but some Java developers are against the word "pointer". Whatever. Just know that the address of the object goes on the stack.

Like so:

int problems = 99;
String name = "Jay-Z";

An array is an object, so it goes on the heap as well. And what about the objects in the array? They get their own heap space, and the address of each object goes inside the array.

So, what gets passed in when you call a method? If you pass in an object, what you're actually passing in is the address of the object. Some might say the "value" of the address, and some say it's just a reference to the object. This is the genesis of the holy war between "reference" and "value" proponents. What you call it isn't as important as that you understand that what's getting passed in is the address to the object.

One String gets created and space for it is allocated in the heap, and the address to the string is stored on the stack and given the identifier hisName, since the address of the second String is the same as the first, no new String is created and no new heap space is allocated, but a new identifier is created on the stack. Then we call shout(): a new stack frame is created and a new identifier, name is created and assigned the address of the already-existing String.

However, you should have followed up with a more complex example where a function appears to alter a variable to whose address it has a reference.
– Brian PetersonNov 1 '13 at 6:53

25

People are not "dancing around the real issue" of stack vs heap, because that's not the real issue. It's an implementation detail at best, and downright wrong at worst. (It's quite possible for objects to live on the stack; google "escape analysis". And a huge number of objects contain primitives that probably don't live on the stack.) The real issue is exactly the difference between reference types and value types -- in particular, that the value of a reference-type variable is a reference, not the object it refers to.
– cHaoDec 18 '13 at 4:48

7

It's an "implementation detail" in that Java is never required to actually show you where an object lives in memory, and in fact seems determined to avoid leaking that info. It could put the object on the stack, and you'd never know. If you care, you're focusing on the wrong thing -- and in this case, that means ignoring the real issue.
– cHaoDec 18 '13 at 14:38

8

And either way, "primitives go on the stack" is incorrect. Primitive local variables go on the stack. (If they haven't been optimized away, of course.) But then, so do local reference variables. And primitive members defined within an object live wherever the object lives.
– cHaoDec 18 '13 at 14:55

8

Agree with the comments here. Stack/heap is a side issue, and not relevant. Some variables may be on the stack, some are in static memory (static variables), and plenty live on the heap (all object member variables). NONE of these variables can be passed by reference: from a called method it is NEVER possible to change the value of a variable that is passed as an argument. Therefore, there is no pass-by-reference in Java.
– fishinearMar 2 '14 at 15:37

Just to show the contrast, compare the following C++ and Java snippets:

In C++: Note: Bad code - memory leaks! But it demonstrates the point.

void cppMethod(int val, int &ref, Dog obj, Dog &objRef, Dog *objPtr, Dog *&objPtrRef)
{
val = 7; // Modifies the copy
ref = 7; // Modifies the original variable
obj.SetName("obj"); // Modifies the copy of Dog passed
objRef.SetName("objRef"); // Modifies the original Dog passed
objPtr->SetName("objPtr"); // Modifies the original Dog pointed to
// by the copy of the pointer passed.
objPtr = new Dog("newObjPtr"); // Modifies the copy of the pointer,
// leaving the original object alone.
objPtrRef->SetName("objRefPtr"); // Modifies the original Dog pointed to
// by the original pointer passed.
objPtrRef = new Dog("newObjPtrRef"); // Modifies the original pointer passed
}
int main()
{
int a = 0;
int b = 0;
Dog d0 = Dog("d0");
Dog d1 = Dog("d1");
Dog *d2 = new Dog("d2");
Dog *d3 = new Dog("d3");
cppMethod(a, b, d0, d1, d2, d3);
// a is still set to 0
// b is now set to 7
// d0 still have name "d0"
// d1 now has name "objRef"
// d2 now has name "objPtr"
// d3 now has name "newObjPtrRef"
}

In Java,

public static void javaMethod(int val, Dog objPtr)
{
val = 7; // Modifies the copy
objPtr.SetName("objPtr") // Modifies the original Dog pointed to
// by the copy of the pointer passed.
objPtr = new Dog("newObjPtr"); // Modifies the copy of the pointer,
// leaving the original object alone.
}
public static void main()
{
int a = 0;
Dog d0 = new Dog("d0");
javaMethod(a, d0);
// a is still set to 0
// d0 now has name "objPtr"
}

Java only has the two types of passing: by value for built-in types, and by value of the pointer for object types.

+1 I would also add Dog **objPtrPtr to the C++ example, that way we can modify what the pointer "points to".
– AmroJul 2 '14 at 3:59

This is one of the best answers I have seen so far. It mostly avoids the irrelevant semantics argument of "reference vs value of the reference" present elsewhere and instead discusses the mechanics of what actually happens. I had to give most other "pass-by-value" answers -1 because of their self-contradictory or factually false content, but this one gets +1 instead.
– AaronAug 2 '17 at 15:32

I can't believe that nobody mentioned Barbara Liskov yet. When she designed CLU in 1974, she ran into this same terminology problem, and she invented the term call by sharing (also known as call by object-sharing and call by object) for this specific case of "call by value where the value is a reference".

I like this distinction in nomenclature. It's unfortunate that Java supports call by sharing for objects, but not call by value (as does C++). Java supports call by value only for primitive data types and not composite data types.
– Derek MaharSep 8 '10 at 14:16

2

I really don't think we needed an extra term - it's simply pass-by-value for a specific type of value. Would adding "call by primitive" add any clarification?
– Scott StanchfieldOct 25 '10 at 20:03

So I can pass-by-reference by sharing some global context object, or even passing a context object that contains other references? I still pass-by-value, but at least I have access to references I can modify and make them point to something else.
– YoYoJan 8 '16 at 0:14

will print out "Hah!" instead of null. The reason this works is because bar is a copy of the value of baz, which is just a reference to "Hah!". If it were the actual reference itself, then foo would have redefined baz to null.

The crux of the matter is that the word reference in the expression "pass by reference" means something completely different from the usual meaning of the word reference in Java.

Usually in Java reference means a a reference to an object. But the technical terms pass by reference/value from programming language theory is talking about a reference to the memory cell holding the variable, which is something completely different.

References pnt1 and pnt2 are passed by value to the tricky method, which means that now yours references pnt1 and pnt2 have their copies named arg1 and arg2.So pnt1 and arg1points to the same object. (Same for the pnt2 and arg2)

In the tricky method:

arg1.x = 100;
arg1.y = 100;

Next in the tricky method

Point temp = arg1;
arg1 = arg2;
arg2 = temp;

Here, you first create new temp Point reference which will point on same place like arg1 reference. Then you move reference arg1 to point to the same place like arg2 reference.
Finally arg2 will point to the same place like temp.

From here scope of tricky method is gone and you don't have access any more to the references: arg1, arg2, temp. But important note is that everything you do with these references when they are 'in life' will permanently affect object on which they are point to.

So after executing method tricky, when you return to main, you have this situation:

A reference is always a value when represented, no matter what language you use.

Getting an outside of the box view, let's look at Assembly or some low level memory management. At the CPU level a reference to anything immediately becomes a value if it gets written to memory or to one of the CPU registers. (That is why pointer is a good definition. It is a value, which has a purpose at the same time).

Data in memory has a Location and at that location there is a value (byte,word, whatever). In Assembly we have a convenient solution to give a Name to certain Location (aka variable), but when compiling the code, the assembler simply replaces Name with the designated location just like your browser replaces domain names with IP addresses.

Down to the core it is technically impossible to pass a reference to anything in any language without representing it (when it immediately becomes a value).

Lets say we have a variable Foo, its Location is at the 47th byte in memory and its Value is 5. We have another variable Ref2Foo which is at 223rd byte in memory, and its value will be 47. This Ref2Foo might be a technical variable, not explicitly created by the program. If you just look at 5 and 47 without any other information, you will see just two Values.
If you use them as references then to reach to 5 we have to travel:

If we want to call a method/function/procedure with Foo's value, there are a few possible way to pass the variable to the method, depending on the language and its several method invocation modes:

5 gets copied to one of the CPU registers (ie. EAX).

5 gets PUSHd to the stack.

47 gets copied to one of the CPU registers

47 PUSHd to the stack.

223 gets copied to one of the CPU registers.

223 gets PUSHd to the stack.

In every cases above a value - a copy of an existing value - has been created, it is now upto the receiving method to handle it. When you write "Foo" inside the method, it is either read out from EAX, or automatically dereferenced, or double dereferenced, the process depends on how the language works and/or what the type of Foo dictates. This is hidden from the developer until she circumvents the dereferencing process. So a reference is a value when represented, because a reference is a value that has to be processed (at language level).

Now we have passed Foo to the method:

in case 1. and 2. if you change Foo (Foo = 9) it only affects local scope as you have a copy of the Value. From inside the method we cannot even determine where in memory the original Foo was located.

in case 3. and 4. if you use default language constructs and change Foo (Foo = 11), it could change Foo globally (depends on the language, ie. Java or like Pascal's procedure findMin(x, y, z: integer;var m: integer);). However if the language allows you to circumvent the dereference process, you can change 47, say to 49. At that point Foo seems to have been changed if you read it, because you have changed the local pointer to it. And if you were to modify this Foo inside the method (Foo = 12) you will probably FUBAR the execution of the program (aka. segfault) because you will write to a different memory than expected, you can even modify an area that is destined to hold executable program and writing to it will modify running code (Foo is now not at 47). BUT Foo's value of 47 did not change globally, only the one inside the method, because 47 was also a copy to the method.

in case 5. and 6. if you modify 223 inside the method it creates the same mayhem as in 3. or 4. (a pointer, pointing to a now bad value, that is again used as a pointer) but this is still a local problem, as 223 was copied. However if you are able to dereference Ref2Foo (that is 223), reach to and modify the pointed value 47, say, to 49, it will affect Foo globally, because in this case the methods got a copy of 223 but the referenced 47 exists only once, and changing that to 49 will lead every Ref2Foo double-dereferencing to a wrong value.

Nitpicking on insignificant details, even languages that do pass-by-reference will pass values to functions, but those functions know that they have to use it for dereferencing purposes. This pass-the-reference-as-value is just hidden from the programmer because it is practically useless and the terminology is only pass-by-reference.

Strict pass-by-value is also useless, it would mean that a 100 Mbyte array should have to be copied every time we call a method with the array as argument, therefore Java cannot be stricly pass-by-value. Every language would pass a reference to this huge array (as a value) and either employs copy-on-write mechanism if that array can be changed locally inside the method or allows the method (as Java does) to modify the array globally (from the caller's view) and a few languages allows to modify the Value of the reference itself.

So in short and in Java's own terminology, Java is pass-by-value where value can be: either a real value or a value that is a representation of a reference.

In a language with pass-by-reference, the thing which is passed (the reference) is ephemeral; the recipient is not "supposed" to copy it. In Java, passing an array is passed is an "object identifier"--equivalent to a slip of paper which says "Object #24601", when the 24601st object constructed was an array. The recipient can copy "Object #24601" anywhere it wants, and anyone with a slip of paper saying "Object #24601" can do anything it wants with any of the array elements. The pattern of bits that is passed wouldn't actually say "Object #24601", of course, but...
– supercatJan 10 '14 at 17:02

...the key point is that the recipient of the object-id that identifies the array can store that object-id wherever it wants and give it to whomever it wants, and any recipient would be able to access or modify the array whenever it wants. By contrast, if an array were passed by reference in a language like Pascal which supports such things, the called method could do whatever it wanted with the array, but could not store the reference in such a way as to allow code to modify the array after it returned.
– supercatJan 10 '14 at 17:04

Indeed, in Pascal you can get the address of every variable, be it passed-by-reference or locally copied, addr does it untyped,@ does it with type, and you can modify the referenced variable later (except locally copied ones). But I don't see the point why you would do that. That slip of paper in your example (Object #24601) is a reference,its purpose is to help find the array in memory, it does not contain any array data in itself. If you restart your program, the same array might get a different object-id even if its content will be the same as it has been in the previous run.
– karatedogJan 10 '14 at 22:48

I'd thought the "@" operator was not part of standard Pascal, but was implemented as a common extension. Is it part of the standard? My point was that in a language with true pass-by-ref, and no ability to construct a non-ephemeral pointer to an ephemeral object, code which holds the only reference to an array, anywhere in the universe, before passing the array by reference can know that unless the recipient "cheats" it will still hold the only reference afterward. The only safe way to accomplish that in Java would be to construct a temporary object...
– supercatJan 10 '14 at 22:52

...which encapsulates an AtomicReference and neither exposes the reference nor its target, but instead includes methods to do things to the target; once the code to which the object was passed returns, the AtomicReference [to which its creator kept a direct reference] should be invalidated and abandoned. That would provide the proper semantics, but it would be slow and icky.
– supercatJan 10 '14 at 22:54

As we all know it will create an object in the heap and return the reference value back to t. For example, suppose the value of t is 0x100234 (we don't know the actual JVM internal value, this is just an example) .

new PassByValue().changeValue(t);

When passing reference t to the function it will not directly pass the actual reference value of object test, but it will create a copy of t and then pass it to the function. Since it is passing by value, it passes a copy of the variable rather than the actual reference of it. Since we said the value of t was 0x100234, both t and f will have the same value and hence they will point to the same object.

If you change anything in the function using reference f it will modify the existing contents of the object. That is why we got the output changevalue, which is updated in the function.

Excellent answer, the key statement: "When passing reference t to the function it will not directly pass the actual reference value of object test, but it will create a copy of t and then pass it to the function"
– pedram bashiriMay 4 at 16:25

When the method or constructor is invoked (§15.12), the values of the actual argument expressions initialize newly created parameter variables, each of the declared type, before execution of the body of the method or constructor. The Identifier that appears in the DeclaratorId may be used as a simple name in the body of the method or constructor to refer to the formal parameter.

As far as I know, Java only knows call by value. This means for primitive datatypes you will work with an copy and for objects you will work with an copy of the reference to the objects. However I think there are some pitfalls; for example, this will not work:

This will populate Hello World and not World Hello because in the swap function you use copys which have no impact on the references in the main. But if your objects are not immutable you can change it for example:

+1 for the swap test -- probably the most straightforward and relatable way to distinguish between passing by reference and passing a reference by value. Iff you can easily write a function swap(a, b) that (1) swaps a and b from the caller's POV, (2) is type-agnostic to the extent that static typing allows (meaning using it with another type requires nothing more than changing the declared types of a and b), and (3) doesn't require the caller to explicitly pass a pointer or name, then the language supports passing by reference.
– cHaoDec 17 '13 at 21:24

"..for primitive datatypes you will work with an copy and for objects you will work with an copy of the reference to the objects" - perfectly written!
– RaúlNov 24 '16 at 13:16

Some people say primitive types and 'String' are 'pass by value'
and objects are 'pass by reference'.

But from this example, we can understand that it is infact pass by value only,
keeping in mind that here we are passing the reference as the value.
ie: reference is passed by value.
That's why are able to change and still it holds true after the local scope.
But we cannot change the actual reference outside the original scope.
what that means is demonstrated by next example of PassByValueObjectCase2.

As was explained in previous answers, in Java you're passing a pointer to the array as a value into getValues. That is enough, because the method then modifies the array element, and by convention you're expecting element 0 to contain the return value. Obviously you can do this in other ways, such as structuring your code so this isn't necessary, or constructing a class that can contain the return value or allow it to be set. But the simple pattern available to you in C++ above is not available in Java.

In call-by-reference evaluation (also referred to as
pass-by-reference), a function receives an implicit reference to a
variable used as argument, rather than a copy of its value. This
typically means that the function can modify (i.e. assign to) the
variable used as argument—something that will be seen by its caller.

In call-by-value, the argument expression is evaluated, and the
resulting value is bound to the corresponding variable in the function [...].
If the function or procedure is able to assign values to its
parameters, only its local copy is assigned [...].

When the method or constructor is invoked (§15.12), the values of the
actual argument expressions initialize newly created parameter
variables, each of the declared type, before execution of the body of
the method or constructor.

So it assigns (or binds) the value of the argument to the corresponding parameter variable.

There are three kinds of reference types: class types, array types,
and interface types. Their values are references to dynamically
created class instances, arrays, or class instances or arrays that
implement interfaces, respectively.

The reference values (often just references) are pointers to these objects, and a special null reference, which refers to no object.

The value of an argument (of some reference type) is a pointer to an object. Note that a variable, an invocation of a method with a reference type return type, and an instance creation expression (new ...) all resolve to a reference type value.

all bind the value of a reference to a String instance to the method's newly created parameter, param. This is exactly what the definition of pass-by-value describes. As such, Java is pass-by-value.

The fact that you can follow the reference to invoke a method or access a field of the referenced object is completely irrelevant to the conversation. The definition of pass-by-reference was

This typically means that the function can modify (i.e. assign to) the
variable used as argument—something that will be seen by its caller.

In Java, modifying the variable means reassigning it. In Java, if you reassigned the variable within the method, it would go unnoticed to the caller. Modifying the object referenced by the variable is a different concept entirely.

Primitive values are also defined in the Java Virtual Machine Specification, here. The value of the type is the corresponding integral or floating point value, encoded appropriately (8, 16, 32, 64, etc. bits).

If it's a primitive data type these bits contain the value of the primitive data type itself, That's why if we change the value of header inside the method then it does not reflect the changes outside.

If it's an object data type like Foo foo=new Foo() then in this case copy of the address of the object passes like file shortcut , suppose we have a text file abc.txt at C:\desktop and suppose we make shortcut of the same file and put this inside C:\desktop\abc-shortcut so when you access the file from C:\desktop\abc.txt and write 'Stack Overflow' and close the file and again you open the file from shortcut then you write ' is the largest online community for programmers to learn' then total file change will be 'Stack Overflow is the largest online community for programmers to learn' which means it doesn't matter from where you open the file , each time we were accessing the same file , here we can assume Foo as a file and suppose foo stored at 123hd7h(original address like C:\desktop\abc.txt ) address and 234jdid(copied address like C:\desktop\abc-shortcut which actually contains the original address of the file inside) ..
So for better understanding make shortcut file and feel...

The distinction, or perhaps just the way I remember as I used to be under the same impression as the original poster is this: Java is always pass by value. All objects( in Java, anything except for primitives) in Java are references. These references are passed by value.

I find your second-to-last sentence very misleading. It's not true that "all objects in Java are references". It's only the references to those objects that are references.
– Dawood ibn KareemJan 25 '17 at 10:09

This happens because iA and iB are new local reference variables that have the same value of the passed references (they point to a and b respectively). So, trying to change the references of iA or iB will only change in the local scope and not outside of this method.

I always think of it as "pass by copy". It is a copy of the value be it primitive or reference. If it is a primitive it is a copy of the bits that are the value and if it is an Object it is a copy of the reference.

Java arguments are all passed by value (the reference is copied when used by the method) :

In the case of primitive types, Java behaviour is simple:
The value is copied in another instance of the primitive type.

In case of Objects, this is the same:
Object variables are pointers (buckets) holding only Object’s address that was created using the "new" keyword, and are copied like primitive types.

The behaviour can appear different from primitive types: Because the copied object-variable contains the same address (to the same Object)
Object's content/members might still be modified within a method and later access outside, giving the illusion that the (containing) Object itself was passed by reference.

"String" Objects appear to be a perfect counter-example to the urban legend saying that "Objects are passed by reference":

In effect, within a method you will never be able, to update the value of a String passed as argument:

A String Object, holds characters by an array declared final that can't be modified.
Only the address of the Object might be replaced by another using "new".
Using "new" to update the variable, will not let the Object be accessed from outside, since the variable was initially passed by value and copied.

This is yet another great example of the fallacy of the "it is not pass by reference" semantics argument. This answer says right in the bold, first sentence: "only references are passed." Either a reference is passed, or a reference is not passed. You just said yourself that a reference is passed. By saying "it is not passed by reference since a reference is passed but..." you are trying to make a point by mangling English.
– AaronAug 2 '17 at 15:07

@Aaron "Pass by reference" does not mean "pass a value that is a member of a type that is called a 'reference' in Java". The two uses of "reference" mean different things.
– philipxySep 27 '17 at 8:36

+1. What C does support, is treating references (which C calls pointers) as first-class values, and then passing them by value.
– Jörg W MittagSep 7 '10 at 22:02

1

Yeah, in C you can create pointers not only on objects, but on arbitrary variables - so you can easily simulate "call-by-reference" of any variable. In Java this works only for variables which have a surrounding object, which you can give.
– Paŭlo EbermannFeb 3 '11 at 1:27

To make a long story short, Java objects have some very peculiar properties.

In general, Java has primitive types (int, bool, char, double, etc) that are passed directly by value. Then Java has objects (everything that derives from java.lang.Object). Objects are actually always handled through a reference (a reference being a pointer that you can't touch). That means that in effect, objects are passed by reference, as the references are normally not interesting. It does however mean that you cannot change which object is pointed to as the reference itself is passed by value.

Does this sound strange and confusing? Let's consider how C implements pass by reference and pass by value. In C, the default convention is pass by value. void foo(int x) passes an int by value. void foo(int *x) is a function that does not want an int a, but a pointer to an int: foo(&a). One would use this with the & operator to pass a variable address.

Take this to C++, and we have references. References are basically (in this context) syntactic sugar that hide the pointer part of the equation: void foo(int &x) is called by foo(a), where the compiler itself knows that it is a reference and the address of the non-reference a should be passed. In Java, all variables referring to objects are actually of reference type, in effect forcing call by reference for most intends and purposes without the fine grained control (and complexity) afforded by, for example, C++.

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).