Introduction

Java is strictly pass-by-value. The confusion comes from the fact that when you pass an object variable, the copied value is a reference to the object. That copied reference still points to the same object, so the method can mutate the object, but it cannot replace the caller's variable itself.

What Pass-by-Value Means in Java

When you call a method, Java copies the argument value into the parameter. The parameter is a new local variable inside the called method.

For primitives, this is easy to see:

1public class Demo {
2    static void change(int x) {
3        x = 99;
4    }
5
6    public static void main(String[] args) {
7        int a = 10;
8        change(a);
9        System.out.println(a); // still 10
10    }
11}

a stays 10 because the method only modified its own local copy of the value.

Why Objects Cause Confusion

With objects, the copied value is a reference. Both the caller and the callee now hold references to the same object, so object mutation is visible through either reference.

1class Box {
2    int value;
3}
4
5public class Demo {
6    static void mutate(Box box) {
7        box.value = 42;
8    }
9
10    public static void main(String[] args) {
11        Box b = new Box();
12        b.value = 10;
13        mutate(b);
14        System.out.println(b.value); // 42
15    }
16}

This does not mean Java passed b by reference. It means Java copied the reference value, and both copies point to the same Box object.

Reassigning the Parameter Proves the Point

If Java were pass-by-reference, reassigning the parameter inside the method would change the caller's variable too. But it does not:

1class Box {
2    int value;
3}
4
5public class Demo {
6    static void reassign(Box box) {
7        box = new Box();
8        box.value = 99;
9    }
10
11    public static void main(String[] args) {
12        Box b = new Box();
13        b.value = 10;
14        reassign(b);
15        System.out.println(b.value); // still 10
16    }
17}

The method changed only its own local copy of the reference. The caller's variable b still points to the original object.

A Useful Mental Model

Think of it this way:

• primitives: Java copies the primitive value
• objects: Java copies the reference value

In both cases, the rule is the same: Java passes by value.

The only difference is what the value represents.

Why "Pass-by-Reference" Sounds Plausible

People often say Java "feels" pass-by-reference because mutations to objects are visible outside the method. That observation is real, but the explanation is not pass-by-reference semantics. The explanation is shared object identity through copied references.

This distinction matters when reasoning about APIs, immutability, defensive copying, and side effects.

Common Pitfalls

The biggest mistake is teaching "objects are passed by reference" as a shortcut. That creates confusion later when reassignment examples do not behave the way true pass-by-reference would imply.

Another issue is assuming methods can swap caller variables by reassigning parameters. They cannot. A swap method for object references does not work the way it would in a true pass-by-reference language.

Developers also sometimes overlook object mutation entirely and think pass-by-value means nothing can change outside the method. That is also false when the copied value is a reference to a mutable object.

Finally, when API clarity matters, immutable objects help reduce this confusion because methods cannot secretly mutate shared state through copied references.

Summary

• Java is always pass-by-value.
• For primitives, the copied value is the primitive itself.
• For objects, the copied value is the reference to the object.
• Methods can mutate a shared object through the copied reference, but they cannot replace the caller's variable.
• Reassigning a parameter does not prove pass-by-reference; it proves the opposite.