Is Java pass-by-value or pass-by-reference?

The Answer

Say this in the room. 45 seconds.

• Java is pass-by-value. Always. There is no pass-by-reference in Java.
• For a primitive, the value copied is the number.
• For an object, the value copied is the reference — the address, not the object.
• So the method gets its own copy of the arrow pointing at your object. Both arrows point at the same thing.
• That means the method can mutate your object — list.add(...), sb.append(...) — and you will see it.
• But it cannot make your variable point somewhere else. Reassigning the parameter only moves the method's copy of the arrow.
• The proof: write a swap method. It fails for objects too, not just primitives. If Java were pass-by-reference, swapping would work.

Understand It

Two words that get conflated

The confusion is that "reference" appears in both phrases. Pull them apart:

Java only ever does the first. When the variable holds an object, its value is a reference — so a reference gets copied. A copied reference is not pass-by-reference. That single sentence is the whole answer, and it's why "Java is pass-by-reference for objects" is wrong rather than merely imprecise.

The primitive case nobody argues about

int x = 1;
int y = 2;
swapPrimitives(x, y);
System.out.println("x=" + x + " y=" + y);

x=1 y=2

The method got copies. It swapped its copies. Nothing happened out here. Everyone accepts this.

The object case, which settles the argument

Now the identical method, on objects:

StringBuilder p = new StringBuilder("first");
StringBuilder q = new StringBuilder("second");
swapObjects(p, q);
System.out.println("p=" + p + " q=" + q);

p=first q=second

Nothing swapped. This is the experiment that decides the question, and it's the one most articles skip — they demonstrate the primitive swap, which tells you nothing about objects, and then assert that objects behave differently.

In a genuinely pass-by-reference language, swapObjects would work: the parameters would be aliases for p and q themselves, and assigning to them would reassign the caller's variables. That's exactly what C++ void swap(T& a, T& b) does. Java cannot express it. Not with a keyword, not with a trick — the language has no syntax for it.

But methods clearly do change my objects

They do, and this is where the intuition comes from. Both arrows point at one object, so anything the method does to that object is visible to you:

StringBuilder mutated = new StringBuilder("original");
mutate(mutated);
System.out.println("mutate()   -> " + mutated);

StringBuilder replaced = new StringBuilder("original");
reassign(replaced);
System.out.println("reassign() -> " + replaced);

mutate()   -> original mutated
reassign() -> original

Same parameter type, same call shape, opposite outcomes. The difference is one word in the method body:

• sb.append(...) — follow the arrow, change the object. You see it.
• sb = new StringBuilder(...) — point the method's own arrow somewhere else. You see nothing.

Draw it once and you never get this wrong again:

before the call          caller's variable ──────► [ "original" ]

inside the method        caller's variable ──────► [ "original" ]
                         parameter (a copy) ─────►      ▲
                                                        │
  sb.append("x")     ── changes the box ─────────────────┘   caller sees it

  sb = new ...       ── moves only the parameter's arrow      caller sees nothing
                         parameter ────► [ "brand new" ]

Arrays are objects, so the same split applies

int[] numbers = { 1, 2, 3 };

mutateArray(numbers);
System.out.println("after mutateArray   : " + Arrays.toString(numbers));

reassignArray(numbers);
System.out.println("after reassignArray : " + Arrays.toString(numbers));

after mutateArray   : [99, 2, 3]
after reassignArray : [99, 2, 3]

Writing into a slot is visible. Replacing the whole array is not — the second call did nothing at all, which is why "the method takes an array and returns nothing" is nearly always a bug when the method meant to replace its contents.

Why String and Integer feel like exceptions

They aren't. They're immutable, so the mutating half of the story simply isn't available:

String text = "hello";
tryToChangeString(text);
System.out.println("String  -> " + text);

Integer count = 5;
tryToChangeInteger(count);
System.out.println("Integer -> " + count);

String  -> hello
Integer -> 5

s = s + " changed" builds a new String and points the parameter at it. i = i + 100 unboxes, adds, and boxes into a new Integer. Neither can modify the original because neither type has a mutator at all.

This is why immutable types are easier to reason about: with StringBuilder you have to know whether the method mutates or reassigns. With String there is only one possibility. Autoboxing makes it worse rather than better — Integer count reads like a plain number, so people expect count to change, and the boxing hides that an immutable object was involved.

What to do about it

Three practical consequences.

You cannot write a swap method in Java. Return a value, return a small record or array holding both, or mutate a container the caller owns. If you find yourself wanting output parameters, that's a design signal.

A method that takes your mutable object can change it. That's the argument for immutability at boundaries: records, List.copyOf, defensive copies. If a method must not modify your list, don't hand it a mutable one.

"Pass by reference" as a phrase is fine in casual speech and wrong in an interview. The interviewer is checking whether you know the difference between copying an arrow and sharing a variable.

Interviewer's Next Move

The question after the question. This is what the round is actually testing.

1. "So objects are passed by reference?" No. The reference is passed by value — the method gets its own copy of it. Both copies point at the same object, which is why mutation is visible, but the method cannot repoint the caller's variable. A copied reference is not pass-by-reference.

2. "Prove it." Write swap(a, b) and call it with two objects. It fails, exactly as it does for primitives. In a pass-by-reference language the parameters would alias the caller's variables and the swap would work — that's what C++ T& does. Java has no syntax for it.

3. "Then why did my list change after I passed it to a method?" Because the method followed the reference and mutated the object. list.add(x) changes the object both arrows point at. list = new ArrayList<>() inside the method changes nothing for you.

4. "Are arrays special?" No, arrays are objects. arr[0] = 99 is visible to the caller; arr = new int[]{...} is not. A method that intends to replace an array's contents has to write into the existing one or return a new array.

5. "Why do String and Integer seem to behave differently?" They're immutable, so there is no mutation to observe — only reassignment, which is never visible. Nothing about parameter passing changes. With Integer autoboxing hides that an object was involved at all, which is where the confusion usually starts.

6. "How would you write a method that swaps two values, then?" You don't, in the C sense. Return both — a record, an array, or a small holder object the caller passes in and the method mutates. Wanting output parameters usually means the method should be returning something instead.

Code traps

Trap A — predict before you run:

static void grow(List<String> list) {
    list.add("added");
    list = new ArrayList<>();
    list.add("invisible");
}

List<String> items = new ArrayList<>();
grow(items);
System.out.println(items);

Trap B:

static void clear(StringBuilder sb) {
    sb = null;
}

StringBuilder sb = new StringBuilder("still here");
clear(sb);
System.out.println(sb.length());

Common wrong answers

Check Yourself

Q1. In one sentence, why can a method change your object but not replace it?

Q2. Which single experiment settles "is Java pass-by-reference?" and what does it show?

Q3. You must guarantee a method cannot modify the list you pass it. What do you do?

Practice