Java Is Always Pass-by-Value

Why this matters

• This one rule explains why a method sometimes appears to modify your data and sometimes appears to ignore your changes entirely.
• "Does Java pass by reference?" is asked constantly, and the confident wrong answer is the most common one.
• Once you hold this rule, defensive copying and immutability stop feeling like ceremony and start looking necessary.

The rule, applied twice

Java is always pass-by-value. There is no second mode. What differs is what the value is.

Primitives: completely isolated

static void increment(int value) {
    value = value + 1;
    System.out.println("inside:  " + value);
}

public static void main(String[] args) {
    int count = 10;
    increment(count);
    System.out.println("outside: " + count);
}

inside:  11
outside: 10

The method received a copy of 10. Nothing it does to that copy can reach count.

Objects: mutation travels, reassignment does not

This is the pair of behaviours that confuses people, and seeing them side by side settles it.

static void mutate(StringBuilder text) {
    text.append(" world");           // changes the shared object
}

static void reassign(StringBuilder text) {
    text = new StringBuilder("replaced");   // changes only the local copy
    text.append("!");
}

public static void main(String[] args) {
    StringBuilder greeting = new StringBuilder("hello");

    mutate(greeting);
    System.out.println(greeting);     // hello world

    reassign(greeting);
    System.out.println(greeting);     // hello world — unchanged
}

hello world
hello world

Both methods received the same address. The first used it to reach the object and modify it. The second threw it away and pointed its own copy somewhere else, which the caller never learns about.

Why swap cannot work

The classic demonstration. There is no way to write a general swap in Java.

static void swap(Integer a, Integer b) {
    Integer temp = a;
    a = b;
    b = temp;
}

public static void main(String[] args) {
    Integer first = 1, second = 2;
    swap(first, second);
    System.out.println(first + ", " + second);   // 1, 2 — nothing happened
}

The method swapped its own two local copies and then returned. Caller variables cannot be rebound from inside a method, full stop. If you need to exchange values, return them — in a record, an array, or by assigning at the call site.

Strings look like an exception but are not

static void change(String text) {
    text = text.toUpperCase();     // creates a new String, rebinds the local copy
}

public static void main(String[] args) {
    String name = "java";
    change(name);
    System.out.println(name);       // java
}

String is immutable, so every operation returns a new object rather than modifying the existing one. There is no mutation available to be visible, and the reassignment is local. Both halves of the rule point the same way.

What this means for your API design

Common misreadings

• "Objects are passed by reference." The reference is passed by value. The distinction is the entire point, and the phrase "pass by reference value" captures it better.
• "Mutation proves pass-by-reference." True pass-by-reference would let a method rebind the caller's variable. Java never allows that.
• "final on a parameter changes the semantics." It only stops reassignment inside the method, which was already invisible outside.
• "Strings behave differently." They behave identically. Immutability simply removes one of the two options.