skip to content

Why can't you write a generic swap(a, b) method in Java that swaps two object references for the caller? What's the underlying reason and how do people work around it?

level: middleimportance: should knowfreq 58%

answer

  1. swap gets copies of references, not the variables
  2. Swapping locals doesn't reach the caller
  3. Route swap through a shared object: array, holder
  4. Collections.swap mutates the list, not your vars
  5. Or return the pair and let caller reassign

basics

~20 s

A swap method only gets copies of the references. Swapping them inside the method just swaps the local copies; the caller's variables are untouched. To swap, you must mutate a shared container the caller can see, like an array or holder object.

solid answer

~50 s

Because Java is pass-by-value, swap(a, b) receives copies of the two references, not the caller's variables themselves. Inside the method you can exchange the two parameters, but that only swaps the local copies; when the method returns, the caller's original variables still hold their original references. There is no way to reseat the caller's variables from inside the method, since Java cannot pass a variable by reference. The standard workarounds all route the swap through a shared mutable object that both sides can reach: swap two elements of an array (arr[i], arr[j]), swap fields of a holder object you pass in, or design the API to return the swapped pair (e.g., a record or an array) and let the caller reassign. Collections.swap(list, i, j) works precisely because it mutates the shared list rather than reassigning caller variables.

code

java · 17 lines
java
// Naive swap: does nothing useful
static <T> void swap(T a, T b) { T t = a; a = b; b = t; }

// Working swap via a shared array
static void swap(Object[] arr, int i, int j) {
    Object t = arr[i]; arr[i] = arr[j]; arr[j] = t;
}

public static void main(String[] x) {
    String p = "P", q = "Q";
    swap(p, q);
    System.out.println(p + q);          // PQ  (no effect)

    Object[] pair = { "P", "Q" };
    swap(pair, 0, 1);
    System.out.println(pair[0] + "" + pair[1]); // QP  (works)
}

go deeper

for a junior

Understand that swap can't see the caller's variables, only copies, so the naive version does nothing; name 'use an array' as the fix.

for a middle

Explain the failure with the copied-reference model and present at least two workarounds (array/holder, or return-the-pair), noting Collections.swap mutates the shared list.

for a senior

Generalize: any output-through-parameter is mutation of a shared object; weigh holder vs return-value designs, and prefer returning immutable results over mutable holders for clarity.

for a principal

Use it as a teaching example of value semantics; discuss API design implications (avoid out-params, prefer returning records/tuples), and how this shapes idiomatic, side-effect-light Java.

## What 'swap' would need A caller-visible swap of two variables `x` and `y` requires the method to *reseat the caller's variables*: make `x` hold what `y` held and vice versa. 'Reseat the caller's variable' is exactly what **pass-by-reference** allows and **pass-by-value forbids**. ## Why the naive version fails ```java static <T> void swap(T a, T b) { T tmp = a; a = b; b = tmp; // swaps LOCAL copies only } String x = "X", y = "Y"; swap(x, y); // x is still "X", y is still "Y" ``` Step by step: 1. `x` holds reference Rx, `y` holds Ry. 2. At the call, Java copies the *values*: `a` gets a copy of Rx, `b` gets a copy of Ry. 3. The body swaps `a` and `b` — now `a` holds Ry, `b` holds Rx. But these are the method's private copies. 4. The method returns; `a` and `b` vanish. `x` still holds Rx, `y` still holds Ry. No swap. The method never had access to the *variables* `x` and `y` — only to copies of their values. There is nothing it can do to reach back and reseat them. This is the fundamental limitation of pass-by-value, and it's the same reason a method can't null out the caller's variable or replace the caller's object with a new one. ## The workarounds — all route through a shared mutable object The trick is: you can't reseat the caller's *variables*, but you CAN mutate a *shared object* both sides reach. So put the two slots you want to swap *inside* such an object. ### 1. Swap array elements ```java static void swap(Object[] arr, int i, int j) { Object tmp = arr[i]; arr[i] = arr[j]; arr[j] = tmp; } Object[] pair = { "X", "Y" }; swap(pair, 0, 1); // pair is now { "Y", "X" } ``` The *array* is a shared object; the elements are slots inside it. `arr` is a copied reference, but it points at the caller's array, so writing `arr[i] = ...` mutates the one array the caller sees. This is exactly how `Collections.swap(list, i, j)` works. ### 2. Holder / mutable wrapper ```java class Holder<T> { T value; } static <T> void swap(Holder<T> a, Holder<T> b) { T tmp = a.value; a.value = b.value; b.value = tmp; } ``` You swap the *fields* of two shared holder objects, not the parameter references. ### 3. Return the swapped pair (functional style) ```java static <T> T[] swapped(T first, T second) { return (T[]) new Object[]{ second, first }; } // or return a record (Pair<A,B>) — caller reassigns: var p = swapped(x, y); x = p[0]; y = p[1]; ``` The method computes the result and *returns* it; the caller does the reassignment, which only the caller can do. ## Takeaway The inability to write a caller-visible `swap(a, b)` is a clean, memorable proof that Java is pass-by-value. Any 'output through a parameter' in Java is really 'mutate a shared object through its reference' — never 'reseat the caller's variable'.

  • Does Collections.swap(list, i, j) contradict the 'no swap' claim?
    No. It swaps two ELEMENTS inside a shared list (mutation through the list reference), not two caller variables. The list is the shared mutable container; the method never reseats any caller variable.
  • Could you swap two int variables with a method?
    Not directly — primitives are copied by value too, so the method only swaps copies. You'd pass an int[] and swap arr[0]/arr[1], or use a holder, or return the swapped pair. Same shared-container principle.

saying these in an interview costs you the question

  • Believing the naive swap(a,b) works
  • Thinking 'final' or generics could enable a real swap
  • Confusing swapping array elements (works) with swapping parameters (doesn't)
  • Claiming this proves Java is pass-by-reference (it proves the opposite)

context

resolving links…