Is Java Pass-by-Value or Pass-by-Reference?

Java is always pass-by-value. There is no pass-by-reference in Java at all. When you call a method, every argument is copied into the method's own parameter, and the method operates only on its copy.

For primitives this is intuitive: the method gets its own int, and changing it cannot affect the caller's variable. For references it is subtler but the rule is identical — the method gets a copy of the reference, not the reference itself. So if the method reassigns its parameter, the caller sees nothing, because it is writing to the local copy of the pointer. If the method mutates the object the reference points at, the caller does see the change, because both references point at the same object.

public class Main {
    public static void main(String[] args) {
        int original = 10;
        System.out.println("before : " + original);
        tryToChange(original);
        System.out.println("after  : " + original);

        int[] numbers = {1, 2, 3};
        tryToChangeArray(numbers);
        System.out.println("array after : " + numbers[0]);
    }

    static void tryToChange(int value) {
        value = 99;        // changes the local copy only
    }

    static void tryToChangeArray(int[] values) {
        values[0] = 99;   // mutates the shared array
    }
}

The output shows both halves of the rule. The int is unchanged after the call, because only the copy was modified. The array's first element is changed, because both the caller and the method hold references to the same array object and the method mutated what it points at.

The right way to say this in an interview is that Java passes object references by value. The reference is copied; the object is shared. That single sentence resolves almost every argument-passing puzzle, including the classic question about swapping two variables inside a method: it cannot work, because the method only has copies of the references and cannot redirect the caller's variables.

Because the value being copied is a reference, and the reference points at an object that both parties share. The method receives its own copy of the reference, but that copy still points at the same object. So any mutation of the object's internal state is visible to the caller, while any reassignment of the parameter itself is not.

Two common shapes of this show up in interviews. The first is the mutator method, where you pass an object and call a setter or an add method on it. The second is the collection case: a List passed into a method can be added to, removed from or reordered, and the caller sees every change, because the list object is shared even though the reference was copied.

import java.util.ArrayList;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        List<String> names = new ArrayList<>();
        names.add("Ada");
        addName(names, "Grace");
        System.out.println("list   : " + names);

        Counter counter = new Counter();
        System.out.println("count  : " + counter.value);
        increment(counter);
        System.out.println("count  : " + counter.value);

        // Reassigning the parameter is invisible to the caller.
        swapNames(names);
        System.out.println("after swap attempt : " + names);
    }

    static void addName(List<String> list, String name) {
        list.add(name);
    }

    static void increment(Counter counter) {
        counter.value++;
    }

    static void swapNames(List<String> list) {
        list.clear();
    }
}

class Counter {
    int value = 0;
}

Note the last case: clearing the list inside the method is visible to the caller, because it mutates the shared object, whereas assigning a brand-new list to the parameter would not be. If a method genuinely needs to replace the caller's object, it has to return the new value and let the caller reassign its own variable, or the caller has to accept an object that it can mutate in place.