Java is using implicit pointer semantics for Object types and value semantics for primitives.
Value semantics means that you deal directly with values and that you pass copies around. The point here is that when you have a value, you can trust it won't change behind your back.
With pointer semantics, you don't have a value, you have an 'address'. Someone else could alter what is there, you can't know.
Pointer Semantics in C++ :
void foo(Bar * b) . . b->bar() .
You need an * to ask for pointer semantics and -> to call methods on the pointee.
Implicit Pointer Semantics in Java :
void foo(Bar b) . . b.bar() .
Since you don't have the choice of using value semantics, the * isn't needed nor the distinction between -> and ., hence the implicit.
answered Oct 3, 2008 at 9:08 David Pierre David Pierre 9,525 4 4 gold badges 41 41 silver badges 32 32 bronze badgesBasically, value semantics means that assigning one value to another creates a copy:
int x = 1; int y = x; x = 2; // y remains the same!
A special case is a function call which gets passed an argument:
void f(int x) < x = 5; >int a = 1; f(a); // a is still 1
This is actually the same for Java and C++. However, Java knows only a few primitive types, among them int , double , boolean and char , along with enums which behave in this manner. All other types use reference semantics which means that an assignment of one value to another actually redirects a pointer instead of copying the underlying value:
class Foo < int x; public Foo(int x) < this.x = x; >> Foo a = new Foo(42); Foo b = a; // b and a share the same instance! a.x = 32; //b.x is now also changed.
There are a few caveats however. For example, many reference types ( String , Integer …) are actually immutables. Their value cannot be changed and any assignment to them overrides the old value.
Also, arguments still get passed by value. This means that the value of an object passed to a function can be changed but its reference can't:
void f(Foo foo) < foo.x = 42; >void g(Foo foo) < foo = new Foo(42); >Foo a = new Foo(23); f(a); // a.x is now 42! Foo b = new Foo(1); g(b); // b remains unchanged!
answered Oct 3, 2008 at 9:11
Konrad Rudolph Konrad Rudolph
542k 136 136 gold badges 954 954 silver badges 1.2k 1.2k bronze badges
why the special case?
Commented Jul 26, 2015 at 14:12
@morbidCode What special case? Argument passing? It’s not actually a special case, it behaves identical to assignment (it just isn’t an assignment syntactically).
Commented Jul 26, 2015 at 14:15I'm not sure I got it. Do you mean when you pass a to f(x), a copy of a is created, then that copy is asigned the value 5, so when the method returns the copy is gone and the value of the original a stays the same?
Commented Jul 26, 2015 at 14:28Just to be clear, since you and other answers said references are passed by value, while g(Foo) is executing, does b actually have two pointers pointing to it, One already pointing to the original b and another one created inside g(foo)? Same goes for ffoo( and a?
Commented Jul 26, 2015 at 14:42@morbidCode My answer doesn’t contradict those other answers. b doesn’t have two pointers pointing to it, because it is itself a pointer (well actually a reference). So both b and (inside g ) foo refer/point to the same object.
Commented Jul 26, 2015 at 15:00Java is pass by value. C++ can use both, value and reference semantics.
46.7k 22 22 gold badges 134 134 silver badges 194 194 bronze badges answered Oct 3, 2008 at 9:13 Bartosz Blimke Bartosz Blimke 6,598 3 3 gold badges 25 25 silver badges 19 19 bronze badgesThat description is misleading because of Java's hidden pointers (even if the pointers themselves are passed by value.)
Commented Oct 3, 2008 at 10:36@finnw : I agree, but then, Java developers should still understand it that way, because if they hope to change the pointed data inside a function, they will be surprised the original "reference" outside is left untouched. So this is important for them to understand their "references" are copied.
Commented Oct 3, 2008 at 10:58Bartosz: glad to see people spreading my article ;) finnw: "Hidden" is the key word there. We're talking about how someone programs in Java.Implementation mechanics behind the scenes don't change the fact that Java is strictly pass-by-value -- read the Java Language Spec to see it spelled out.
Commented Oct 3, 2008 at 14:50@ScottStanchfield: Would it satisfy you to say that Java, while technically "pass by value", doesn't give programmers the values they really care about? The only values in Java are primitives and references.
Commented Mar 29, 2015 at 21:36@EduardoLeón - not sure what you mean. Programmers will get the values, but they're limited in how they can use them (that's the difference - with pass-by-value, they cannot modify the values; they can only read the primitives or follow the pointers. )
Commented Apr 2, 2015 at 20:58Java uses implicit pointer semantics on variable access (you can not directly edit the reference, it autmatically (implicit) gets resolved to the Object on access) and also uses Pass-by-Value semantics on method parameters passing.
In Java applications, when an object reference is a parameter to a method, you are passing a copy of the reference (pass by value), not the reference itself. Note that the calling method's object reference and the copy are pointing to the same object. This is an important distinction. A Java application does nothing differently when passing parameters of varying types like C++ does. Java applications pass all parameters by value, thus making copies of all parameters regardless of type.
Short: All parameters in Java are passed by value. But that doesn't mean an Object gets copied (like the default in PHP4), but the reference to that object gets copied.
You'll see all explanations and in-depth examples on Pass-by-value semantics in Java applications