Java Pass by Value: 5 Tricky Truths That End Confusion

Ask ten Java developers whether the language is pass by value or reference, and you'll get ten confident answers — split down the middle.

The truth fits in one sentence, but its consequences fill careers. Java always copies the argument. What's surprising is what that copy lets you do.

You'll see exactly when caller state changes and when it can't, the aliasing bug that evaded validation for weeks, and the three habits that make this entire bug class impossible.

The One Rule: Everything Is Copied, Nothing Is Shared Except Objects

Java passes everything by value — full stop. For an int, the method gets a copy of the number. For an object, the method gets a copy of the reference (the pointer to the heap object). There is no third mode hiding in the spec.

This single rule produces both behaviors people argue about. Reassign the parameter and only your local copy repoints — the caller's variable is untouched. Mutate through the reference and you touch the one shared object — the caller sees it.

Memorize the shape: the copy is always shallow (one pointer), the sharing is always of the object. Everything else in this article is that sentence wearing different clothes.

Why Reassignment Never Escapes the Method

Watch reassignment fail to escape. Pass an int counter into increment() and the caller's variable never moves — the method counted on its own copy. Pass a Point and assign p = new Point() inside — the caller still holds the original.

Newcomers find this shocking for objects because the call looks powerful: you handed over 'the object.' But you handed over a copy of the address. Repointing your copy of the address changes nothing about the caller's copy.

This is why swap(a, b) can never work in Java. Both parameters are copies; swapping the copies swaps nothing the caller can see. The language simply has no out-parameters.

class PassDemo {
  static void reset(StringBuilder sb, int n) {
    sb.append("!");      // MUTATION: caller sees this
    sb = new StringBuilder("new"); // REASSIGN: caller never sees this
    n = 99;               // REASSIGN: caller never sees this
  }
  public static void main(String[] a) {
    StringBuilder sb = new StringBuilder("hi");
    int n = 1;
    reset(sb, n);
    System.out.println(sb); // hi!  (mutation stuck, reassign lost)
    System.out.println(n);  // 1    (copy, untouched)
  }
}

Why Mutation Through the Reference Always Escapes

Now watch mutation succeed where reassignment failed. Pass a list into a method that calls list.add(x) and the caller sees the new element — both references point at the same heap object, and add() changed that object's contents.

This is the behavior people mislabel 'pass by reference.' It isn't: the reference was copied. The sharing is of the object, not the variable. The distinction matters because it predicts exactly which operations escape (content changes) and which don't (repointing).

Every collection-passing API in Java runs on this mechanism. Getters that return live lists, constructors that store incoming lists, methods that sort in place — all of them share objects through copied references.

Aliasing: The Bug With No Stack Trace

Aliasing is when two variables own the same object. It happens every time you store a passed-in mutable reference without copying: constructors, setters, caches, and getters returning live fields.

The damage is spooky action at a distance. Validation runs against the list's state on Monday; the caller adds items on Tuesday; your 'validated' object changed without a single call to your code. Logs show nothing because nothing called you.

The defense is mechanical: copy at trust boundaries. new ArrayList<>(incoming) on the way in, List.copyOf(field) or Collections.unmodifiableList on the way out. The copy costs ~20ns per element — the bug it prevents costs days.

Clean Patterns: Mutate, Return, or Hold — Never Confuse

So how should methods affect the caller? Three clean patterns. One: mutate deliberately and document it — list.sort() sorts in place and everyone knows. Two: return the new value — String.substring() never touches the original. Three: accept a mutable holder (AtomicInteger, single-element array) for genuine out-params.

What you must not do is mix patterns silently. A method that sometimes mutates and sometimes returns forces every caller to read the implementation. Name the pattern: withDiscounted() returns new, applyDiscount() mutates.

Modern Java pushes you toward returns: records, List.of(), and immutable carriers make the return-new style natural and the aliasing style nearly unrepresentable.

import java.util.*;

record Batch(List<String> payments) {
  // Compact constructor: defensive copy once, owned forever
  Batch { payments = List.copyOf(payments); }
}\n
class Batches {
  // Return-new pattern: original untouched, result explicit
  static Batch withExtra(Batch b, String p) {
    var next = new ArrayList<>(b.payments());
    next.add(p);
    return new Batch(next);
  }
  public static void main(String[] a) {
    var src = new ArrayList<>(List.of("p1"));
    var b = new Batch(src);
    src.add("sneaky");                       // attacker's mutation
    System.out.println(b.payments());        // [p1] — copy held
    System.out.println(withExtra(b, "p2").payments()); // [p1, p2]
  }
}

The Interview One-Liner and the Habits That Stick

Pull it together as a checklist. Primitives: copies, period — to change a number for the caller, return it. Object reassignment: local only — to replace an object, return the new one. Object mutation: shared — assume the caller sees it and document accordingly.

Constructors and getters: copy mutable collections both directions. Wrappers like Integer and String are immutable — reassigning them inside a method is as invisible as reassigning an int.

Say it in interviews with one line: 'Java copies the reference, shares the object — reassignment is local, mutation is global.' Then prove it with the StringBuilder demo above. Short, exact, and visibly runnable.