Java Does Pass-By-Reference
…almost ![]()
Another update:
After reading some of the comments to this entry, I googled ‘pass-by-reference’ and discovered that the semantic aspect of what the phrase means has been the topic of many topics along time with funny titles such as “More on Java- pass by reference, but not really” or more seriously “Parameter passing in Java - by reference or by value?” or what I consider the clearest, best articulated article on the topic: Java is Pass-By-Value, Dammit!
(end of update)
Next day update:
OK, thanks go to the first 3 commenters: when venturing into the semantic field, this entry is inaccurate. I should have used this title actually: Java Does Pass-A-Reference because it actually passes the reference’s value.
What does this mean? Well, Java passes a reference to the original object; however it passes a copy of its original reference.
After making this clear, you can keep reading because the point I am making - which is that the language’s behaviour, similar to C’s behaviour, should not come as a surprise - still stands and I am glad to be prompted to clarify it since it makes easier for the reader to grasp why modifying the argument does not change the reference ![]()
(end of update)
It is simple: either a function/method argument is an object, in which case a reference is passed, or it is not and the argument’s value is passed.
I just read this blog entry that somehow made it to DZone’s home page: Java Does Not Pass-By-Reference.
Well, it is unfortunate. The author makes the case that Java does not pass a reference to an object in a way that would allow him to manipulate said reference.
Of course, this is correct but I find the examples provided somewhat misguided since references themselves are not here to be manipulated but to let you manipulate the object (or, since he mentions C, the memory space) they reference.
Of course, to stay in tune with his C analogy, I should mention that you can modify the reference’s value itself if you use a pointer to a pointer in your function/method signature. For instance, in C, to modify a char* reference, this would look like this:
void myfunction(char **my_double_dereference)
{
(*mydoublereference) = (char*)malloc(sizeof(char*)*my_size);
}
Now, our original memory space was not modified in the process. However, its reference was lost and replaced with a new reference to a new memory allocation.
C was originally written to be a better macro-assembler. With each new language generation, we are getting further away from the original intent by abstracting the architecture of the machine your program is compiled for. Java is one of the “recent” (Ahem! It’s all relative) languages that tried to free developers from having to worry about pointers. Of course, it quickly became obvious that if, on the one hand, it was easy to write a new program in Java, memory management was not going away and it is very difficult to write clean code if you do not understand its principles. (Note to some commenters: I never wrote that Java does away with pointers)
Note that if you wish to modify references in Java, you can still do that, but you have to be a bit more creative and wrap your reference in another object: this is, for example, how weak references work as you are actually passing a reference to the weak reference’s constructor. Not the object referenced.
Using the same model, let’s rewrite Adam’s Figure 4:
public static void main(String[] args) {
StringBuffer sb1 = new StringBuffer("Hello");
StringBufferWrapper wrapper = new StringBufferWrapper(sb1);
doSomething(wrapper);
sb1 = wrapper.reference;
// what gets printed?
if (sb1 == null) {
System.out.println("sb1 is null");
} else {
System.out.println("sb1 is not null");
}
}
public void doSomething(StringBufferWrapper sb2) {
sb2.reference = null;
}
I hope I didn’t introduce any mistake in my code, it’s a tad late but you get the idea.
As usual, let me know if this elicits any question on this topic or weak references or what not…
Cheers!
If you enjoyed this post, make sure you subscribe to my RSS feed!
Similar Posts:
- One-line variables swap in PHP, Ruby, Perl, Python and C
- Php: It’s the Purpose, Stupid.
- Flex: Render your tree nodes with a line through
- IE7: Not Much Better…
- SXSW Photos…
If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.
Comments
I agree with JavaTek 100%. Saying “It is simple: either a function/method argument is an object… ” reveals a failure of understanding of the basics of the language. All objects in Java are anonymous. It is impossible for a Java function/method/argument/variable to be an object. This is not a semantic quibble.
OK, to be clear, JavaTek, do you agree with my update? I clarify that a reference is passed, indeed by value, so am I correct to assume that it’s not what you are arguing?
ps: reading Frank and Asd’s comments, I see that indeed 10 years later it’s still a hot topic. Funny that.
It is not a terminology issue. Reference and pass by are clearly defined terms. Java pass by value is a crystal clear issue. There is no ambiguity and is definitely a fundamental issue of Java knowledge. Not knowing this is a basic Java 101 issue and I can’t believe people are still arguing over this over a decade later.
JavaTek: You sound a bit like an arrogant ass. This is more of a terminology issue than fundamentally important Java knowledge. Maybe you can explain how the alternative definitions of “pass-by-reference” would lead to shitty or great Java code?
As previous comments states, Java DOES NOT pass arguments by reference, never ever, period. Moreover C DOES NOT pass by reference as well, you are passing pointers by value exactly like in Java, therefore to EMULATE passing by reference pointer to pointer is used.
Guys, thanks for your comments. I have updated my entry accordingly.
JavaTek: I hope you ask your applicants to explain what they mean by that before tossing them.
Java passes by “reference by value”, meaning that the reference to an object is copied, when passed as an argument to a method.
You have a copy of the reference to the same object in the second method, so yes, you can mess with the actual object itself. But you cannot change the reference to a separate object and have it affect the reference in the caller - it just affects the local reference in the called method.
Hence the need to wrap the StringBuffer in your example. To get the effects you are showing, you couldn’t have done that simply by setting the sb2 = null in doSomething(). Hence the reference is copied by value, and passed to a called method.
Java passes by value (primitives and objects). This is not to say that it passes the whole object itself. When passing objects, the JVM makes a copy of the pointer and passes the value of the pointer - therefore pass by value. Yes Java has pointers. Read the JVM spec.
This is an interview question I use and if answered “pass by reference” they are tossed. You can not claim to be an experienced Java programmer if you don’t know this. I worked with a Java Architect that did not know this. After this discussion with him, many other things added up (like why the product was so shitty).
Java does not pass by reference only by value. In your example above sb1 is still passed by value is not touched no matter what you do in doSomething. You can mess with the field reference but that is not changing the calling convention…
Sorry, the comment form is closed at this time.








February 5, 2008 @ 1:08 am
Antirealist, you slightly misread: I did not write “either a Java function/method/argument is an object†but “either a function/method argument is an objectâ€Â, meaning “either an argument is an object…†(you know, when you write the code calling your method, for instance: myfunction(myobject))
A friend of mine just pointed to me that I stepped into a religious war hence the name-calling I am now seeing in these comments. I admit that my original title was meant to be a tad provocative so I guess I’ll take the blame for it.
This is too bad because the original goal of this entry is to clarify a behaviour considered confusing by some through the use of short code samples.