Link Details

I thought this was in the first 5 things everyone learns about Java?

Obviously not, 3 out of 5 job candidates I interview for senior Java programmer positions don't realize this!

seriously?!

Dead serious! It's a shame, but the Java the programmer pool is looking pretty sad these days! Not understanding how == and .equals() work, not understanding that protected access = package + subclass, and worse! At least that's what I am seeing...

That worries me deeply... We're going to be looking for someone over the next couple of months where I am... I'm not looking forward to this... :-(

It is quite worrisome indeed. I'm asking this exact question and similar ones during interviews and it truly amazes me how many 'senior' candidates simply don't know the answer. These are the guys who claim having in excess of 10 years experience with Java and ask a wage that's at least double of what I get.

Of course, nobody knows everything. Some people may know a lot of say the Servlet and JSP api's, but may just never have touched JMS in that 10 year. I'm not complaining about that of course.

But seriously, senior people with >10 year experience and who don't know:

- The difference between stack and heap allocation in Java
- Whether Java uses solely pointers/references to Objects or not
- If Java uses pass-by-reference

My sympathies are with you friend. Thanks for the change of heart on your vote too. :-)

Hehe, I changed my vote in the hope this makes the front page and teaches potential candidate something ;-)

Good luck with your search too!

This is the classic: http://javadude.com/articles/passbyvalue.htm

BTW, I wouldn't care if someone said Java uses pass-by-refernce. Objects in Java are passed using references but not 'by reference'. It's just a misunderstanding or not-understanding of terms.

For better understanding of Java people should learn C before they learn Java.

Agreed it's important not to get tangled up in the terminology -- since of course most programmers will just remember "pass in a primitive, you have a copy... pass in an object, that's the *same* object... but setting the object to null just discards the local handle to it with no effect on the calling code." Or something like that.

That last item is the only difference I can think of where it actually matters that you're passing in a copy of the reference, not the reference itself -- but it's definitely important that they know that.

Right, its always pass-by-value, but the fact that all values (except primitives) are really references, it effectively becomes pass-by-reference for most purposes. If you pass in an array to a method, any changes that method makes to the array (short of assigning it a new reference) will be seen in the original array. Yes you really are passing the value as evidenced by what happens when you try to reassign it, but for any other modification you have to treat it like you would a C pass-by-reference method and be careful of any side effects caused by the function messing with the object.
A lot of people who were brought up on Java and never learned a language like C++ have trouble understanding that as they've never seen a true pass-by-value of objects or a pass-by-reference in action.

>Right, its always pass-by-value, but the fact that all values (except primitives) are really references, it effectively becomes pass-by-reference for most purposes.

As said, the difference between pass-by-reference and passing a pointer by-value is subtle. That does however not mean that we should just ignore that difference. It's not exactly rocket science we're talking about here. Understanding this difference implies you also understand what exactly happens when you do an assignment or create a new Object. This is simply basic knowledge. If so many people hadn't been so ignorant about things, we would never have had this discussion.

I'm not saying you should ignore the difference, and CS curriculum do certainly need to do a better job at teaching students these subtleties. However, it is plain disingenuous to not acknowledge that passing Object references or pointers by value is closer to pass-by-reference than pass-by-value when the value is an actual object. I would much prefer an engineer who mistakenly believes that object references in Java are passed-by-reference than one who mistakenly believes that objects (note the lack of the word 'references') are passed-by-value. And since I've never seen any Java code that attempted to use parameters as if they were pass-by-reference, I'm guessing most of those in the former camp do have at least some understanding of what is going on, they are just unfamiliar with the terminology.

>I'm not saying you should ignore the difference, and CS curriculum do certainly need to do a better job at teaching students these subtleties.

Your experience may vary, but I found that people who actually obtained some CS degree typically understand what's going on. It are the self-educated type of guys who don't grasp (or don't care) for this difference. Often you see that they have learned themselves just enough Java to, seemingly, get the job done. What's under the hood is not important to them.

>I would much prefer an engineer who mistakenly believes that object references in Java are passed-by-reference than one who mistakenly believes that objects (note the lack of the word 'references') are passed-by-value.

To be quite honest, I wouldn't want any of those two in my team, especially not on a senior position. C'mon, what does it say about you as a programmer if you failed to understand some basic behavior of your everyday tool? If you don't understand this difference you probably also don't understand a whole lot of other things.

Not understanding such basics leads to all kinds of unexplainable code constructs. E.g. the kind of code where people pass in a cloned Object for no obvious reason, declare variables as instance variables instead of local variables for no obvious reason, or put an Object back into a collection sometimes later after having done a get. As a maintainer such code is quite hard to understand. You'll often see that such usage patterns are maintained for quite some time by successive programmers, since it's really not clear why the code is doing such things and everybody thinks there is some corner case that requires it.

Until... you find out that the original programmer simply didn't understand some basics of the language, and all of these constructs are based on a false assumption and therefor utterly useless.

That is, my friend, the reason why the difference between pass-by-reference and passing a pointer by-value matters. Code is not only interpreted by the machine, but also communicates meaning to human readers. If the meaning of code is subtly different inside the heads of programmers, misunderstandings and communication error occur.

"Your experience may vary, but I found that people who actually obtained some CS degree typically understand what's going on. It are the self-educated type of guys who don't grasp (or don't care) for this difference. Often you see that they have learned themselves just enough Java to, seemingly, get the job done. What's under the hood is not important to them."
I certainly agree that "self educated" developers often lack deeper knowledge of certain concepts. But nowadays some CS programs do seem to be weakening their curriculum to where they basically just teach their students how to use the JVM API, without teaching deeper concepts.

"To be quite honest, I wouldn't want any of those two in my team, especially not on a senior position. C'mon, what does it say about you as a programmer if you failed to understand some basic behavior of your everyday tool? If you don't understand this difference you probably also don't understand a whole lot of other things. "
Sure, you would much prefer a knowledgeable engineer who is familiar with all these concepts. And if you want them in a senior or high level position, then they really do need to know them. But if the worst you can say about your team is that the code monkey working on some small web application confuses "pass a reference by value" with "pass by reference" (especially when the problem isn't that they don't understand the concepts, they are just confusing the terminology), you really aren't in that bad of a position. There are much worse flaws that developers often have, such as not understanding the difference between lists and sets, not understanding when it is and when it isn't appropriate to store things as instance variables, and not understanding how to write thread safe code (hint, its not simply putting a synchronized keyword in front of the method).

In my experience many Java programming candidates also can't tell you the difference between a List and a Set, or why you must override hashCode when you override equals.

C++ clearly defines references..If you know how C++ uses reference in the function arguments , Its easy to understand java way of passing objects ..otherwise its bit confusing at least for the beginers..
,

The distinction between "pass by reference" and "pass by pointer" is only confusing if you're coming from a C or C++ background. Since Java doesn't have any low-level memory constructs (everything is on the heap), there's no need to explain what's going on. Simply put, if I say to a Java developer "pass by reference", he thinks of the pointer-copy-heap-pass technique. Only developer who've actually worked with raw pointers would find this confusing.

>Since Java doesn't have any low-level memory constructs (everything is on the heap), there's no need to explain what's going on

I don't fully agree with you. At first glance you might think there is no need to understand the difference in Java. Everything is always passed by value, but there is no such thing as a variable that directly names the value of an Object. There are -only- pointers (references) to Objects in Java, and your variables are naming those pointers.

So what is the difference then?

The major difference between passing-by-reference and passing-a-pointer-by-value is that in the latter case you can't assign a new value to the original variable. You can in the former case.

E.g.

Assume we have a method:

void changeFoo(Foo someFoo) {
someFoo = new Foo(3);
}

And some code:

Foo foo = new Foo(1);
changeFoo( foo );
// foo is still a Foo(1) here...

With call-by-reference, after the call to changeFoo(), foo would point to a Foo(2). With call-by-value, where the value is in fact a pointer, the changeFoo() method can change the Foo Object foo points to. However... IT CAN NOT CHANGE -WHAT- foo IS POINTING TO.

It's a pretty obvious difference. Amazing that after all this time there's still discussion about this.

Um, yes exactly...

There is no need to understand the difference in Java because there's no need to even know there *is* a difference in Java. Java has one way to pass parameters: pointer value (with the exception of primitives, which are passed by value). Java developers don't even need to know that there ever was a pass by reference or pass by value (back in the days of C++). As I said, saying Java is "pass by reference" is only confusing to former C++ developers. Even C developers would intuitively understand the semantics, since C doesn't have pass by reference like C++.

>There is no need to understand the difference in Java because there's no need to even know there *is* a difference in Java.

I think it's necessary. Not everyone who comes to Java learns Java as its first language. Not everyone who is using Java will never use any other language.

If you insist on calling passing a pointer by-value "call-by-reference" in java, then you're *severely* confusing people who come from an other language or want to use an other language after Java.

I'm sure you would find it ridiculous when Java called Map a Tree, using logic such as: There is no Tree data structure in Java Collections, so Java programmers don't need to understand the difference between a Map and a Tree; let's just call a Map a Tree. Yet, you're proposing that a well established term should be given another, clearly wrong, name in Java, just because in Java the difference wouldn't matter?

What if we do want to add call-by-reference in a future revision of Java? Are you going to say:

"Well guys, I lied to you all these years. Java in fact never had call-by-reference, but it has now"

or

"Hey you guys, I told you Java always had call-by-reference, but now we have real-call-by-reference"

Wouldn't you feel a bit stupid having to say that? If something is a dog, call it a dog. Don't say it's a cat. If something is a pointer being passed by-value, simply say it's a pointer being passed by-value. Don't cause unnecessary confusion saying it's something else, just because -you- think the difference doesn't matter.

Btw, as mentioned in the reactions on the linked article:

"
Please see the book:
The Java Programming Language, 2nd ed. by Ken Arnold and James Gosling. ISBN 0-201-31006-6. Section 2.6.1 Parameter Values. Page 40. Last two lines of 3rd paragraph clearly states:

"There is exactly one parameter passing mode in Java –pass by value- and that helps keep things simple."
"

and:

"More specifically I would like to refer to Sierra & Bates in their SCJP book. It has an entire section devoted to exactly this topic:

I quote:
Does Java use pass-by-value semantics?

If java passes objects by passing the reference variable instead, does that mean Java uses pass-by-reference for object? Not exactly, although you'll often hear and read that it does. Java is actually pass-by-value for all variables running within a single VM. [...]
It makes no difference if you're passing primitive or reference variables, you are always passing a copy of the bits in the variable. [...] if you're passing an object reference variable, you're passing a copy of the bits representing the reference to an object.
"

If James Gosling, the actual designer of the Java programming language, and Bert Bates who co-creates the Sun SCJP examinations both say Java is pass by value, does not use pass by reference and that you need to be aware of this as a Java programmer, don't you feel that Java may actually not use pass by reference after-all and that you should indeed know about that?

>Since Java doesn't have any low-level memory constructs (everything is on the heap)

Take a look at the memory model of Java RTS: http://www.rtsj.org/specjavadoc/mem_index.html ;)

A giant case of "No shit sherlock"