{"title":"Pass by Value","description":"","content":"Java has exactly one rule for how arguments get into methods, and it never changes: **Java is always pass by value**. There is no pass by reference, not for primitives, not for objects, not for arrays, not for strings. The confusing part is that this single rule produces two very different-looking behaviors depending on the argument type, and the two behaviors are sometimes mistaken for two different rules. This lesson covers what pass by value actually means, why mutating a `Cart` inside a method does change the caller's cart, why reassigning the same `Cart` parameter inside a method does not, and how to articulate this clearly in an interview.\n\n---\n\n# What \"Pass by Value\" Actually Means\n\nA method parameter is just a local variable. When a method is called, Java copies the **value of the argument** into that local variable. Whatever happens to the parameter inside the method happens to a copy. The caller's variable is a separate storage slot in memory and Java does not touch it.\n\nThe key word is \"value\". For a primitive like `int`, the value is the number itself, so a copy of the number ends up in the parameter. For a reference type like a `Cart` object, the value of the variable is **not the object**, it's the **reference**, which is essentially a memory handle that points at the object. So a copy of the reference ends up in the parameter. Both variables, the caller's and the method's, now hold a reference to the same object on the heap.\n\nThat single rule, \"copy the value\", is what produces the two behaviors that can appear inconsistent.\n\n\n```java\npublic class DiscountAttempt {\n public static void main(String[] args) {\n int price = 100;\n applyDiscount(price);\n System.out.println(\"Price after method: \" + price);\n }\n\n static void applyDiscount(int amount) {\n amount = amount - 20;\n System.out.println(\"Inside method: \" + amount);\n }\n}\n```\n\n\nThe method received a copy of the number `100`. It subtracted 20 from its own local copy. The caller's `price` was never touched, because the caller's `price` lives in a different slot in memory than the parameter `amount`. The method had no way to reach back and rewrite it.\n\nThis isn't a quirk of `int`. It's the entire mechanism. Every parameter in Java works this way. The only question is what the \"value\" being copied actually is.\n\n---\n\n# Primitives: The Value Is the Number\n\nFor the eight primitive types (`int`, `long`, `short`, `byte`, `float`, `double`, `char`, `boolean`), the variable's value is the number or character or `true`/`false` itself. Passing a primitive copies that value into the parameter. The two variables, the caller's and the method's, are completely independent storage slots that happen to start out holding the same number.\n\nA small diagram makes this concrete. Suppose `price` is `100` in the caller and `applyDiscount(price)` is called. Inside the method, the parameter `amount` is a new slot with its own copy of `100`. Subtracting 20 from `amount` changes `amount`'s slot. It cannot reach the `price` slot at all.\n\n\n```mermaid\nflowchart LR\n subgraph Caller[\"Caller's frame\"]\n P[\"price
100\"]:::cyan\n end\n\n subgraph Method[\"applyDiscount frame\"]\n A[\"amount
100 (copy)\"]:::orange\n A2[\"amount
80 (after amount = amount - 20)\"]:::green\n end\n\n P -->|\"value copied at call\"| A\n A -->|\"local reassignment\"| A2\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe caller and the method live in two separate frames on the call stack. Each frame has its own slots for its own variables. The arrow at call time is a one-way copy. After that copy, the two slots have no connection at all. Reassigning the method's slot has zero effect on the caller's slot. This is the entire story for primitives.\n\nA second example shows the same thing with a `boolean`.\n\n\n```java\npublic class CartFlag {\n public static void main(String[] args) {\n boolean isEmpty = true;\n markNotEmpty(isEmpty);\n System.out.println(\"Caller sees isEmpty = \" + isEmpty);\n }\n\n static void markNotEmpty(boolean flag) {\n flag = false;\n System.out.println(\"Inside method, flag = \" + flag);\n }\n}\n```\n\n\nSame shape, different type. The method got a copy of `true`. It flipped its own copy to `false`. The caller's `isEmpty` was never reachable from inside the method.\n\n---\n\n# Reference Types: The Value Is the Reference\n\nFor everything that isn't a primitive (objects, arrays, strings, lists, every user-defined class), the variable's value is a **reference**. A reference is a small handle, often described as an address, that points at where the actual object lives on the heap. The variable itself doesn't contain the object's data. It contains a pointer to it.\n\nPassing a reference-type argument copies the reference. The parameter and the caller's variable now hold the same handle, which means they point at the same object on the heap. There is one object. There are two variables that both reach it.\n\nThis is the second behavior, and the source of confusion. Because both variables point at the same object, anything the method does to that object **through the parameter** is visible to the caller. The method didn't reach into the caller's variable. It reached into the shared object, and the caller is looking at that same shared object through its own variable.\n\n\n```java\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class CartMutation {\n public static void main(String[] args) {\n List cart = new ArrayList<>();\n cart.add(\"Wireless Mouse\");\n addItem(cart);\n System.out.println(\"Cart size after method: \" + cart.size());\n System.out.println(\"Cart contents: \" + cart);\n }\n\n static void addItem(List items) {\n items.add(\"Laptop Stand\");\n }\n}\n```\n\n\nThe method received a copy of the reference. The copy still points at the same `ArrayList` on the heap. Calling `items.add(...)` mutates that one shared list. When the caller looks through its own variable, it sees the same list, now with two elements.\n\nThis is not pass by reference. The reference itself was copied. The caller's variable was not changed. What changed was the object that both variables happen to point at.\n\nThe diagram below shows what is happening in memory. Each variable is its own slot. The slots happen to hold the same value (the same handle). The handle points at the one object on the heap.\n\n\n```mermaid\nflowchart LR\n subgraph Caller[\"Caller's frame\"]\n C[\"cart
(reference)\"]:::cyan\n end\n\n subgraph Method[\"addItem frame\"]\n I[\"items
(reference copy)\"]:::orange\n end\n\n Heap[\"ArrayList object on the heap
['Wireless Mouse', 'Laptop Stand']\"]:::green\n\n C -->|\"points to\"| Heap\n I -->|\"points to (same object)\"| Heap\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nTwo arrows. One object. The arrow in the caller's frame and the arrow in the method's frame are independent copies of the same handle. Following either arrow leads to the same `ArrayList`. So when the method calls `items.add(...)`, the addition lands in the one shared list, and the caller sees it because the caller's arrow points at the same list.\n\n---\n\n# Reassigning the Parameter Does Nothing\n\nNow we get to the part where the \"always pass by value\" rule shows its real effect. If pass by reference were really happening for objects, then reassigning the parameter inside a method should also be visible to the caller. It isn't. And it isn't for the same reason the primitive example didn't update the caller's variable: the parameter is a separate slot.\n\n\n```java\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class CartReassign {\n public static void main(String[] args) {\n List cart = new ArrayList<>();\n cart.add(\"Wireless Mouse\");\n replaceCart(cart);\n System.out.println(\"Caller cart size: \" + cart.size());\n System.out.println(\"Caller cart: \" + cart);\n }\n\n static void replaceCart(List items) {\n items = new ArrayList<>();\n items.add(\"Laptop Stand\");\n items.add(\"USB Cable\");\n System.out.println(\"Inside method: \" + items);\n }\n}\n```\n\n\nThis is the line that matters: `items = new ArrayList<>();`. This is not a mutation of the original cart. This is a **reassignment** of the local parameter. The parameter `items` started out pointing at the caller's cart. The new line makes `items` point at a new `ArrayList` instead. The caller's `cart` variable still holds its own reference, which still points at the original list, which still contains the one item it started with.\n\nIf Java were pass by reference, the new `ArrayList` would replace the caller's list. It doesn't, which is a direct proof that Java is pass by value even for objects.\n\nThe mental model is: the parameter is a separate slot. The parameter can be reassigned (changing what's in that slot), and that change is local. The reference in that slot can be followed to modify the object it points at, and that modification is shared because the object is shared. These are two different operations and Java treats them differently.\n\nThe diagram below shows the state right after `items = new ArrayList<>()` runs inside the method.\n\n\n```mermaid\nflowchart LR\n subgraph Caller[\"Caller's frame\"]\n C[\"cart
(reference)\"]:::cyan\n end\n\n subgraph Method[\"replaceCart frame\"]\n I[\"items
(now points at new list)\"]:::orange\n end\n\n Old[\"Original ArrayList
['Wireless Mouse']\"]:::green\n New[\"New ArrayList
['Laptop Stand', 'USB Cable']\"]:::red\n\n C -->|\"still points to\"| Old\n I -->|\"reassigned, now points to\"| New\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nAfter the reassignment, the two arrows point at two different objects. The method's local variable was rebound. The caller's variable was not, because Java never let the method touch the caller's slot in the first place.\n\n---\n\n# The Classic Swap That Doesn't Work\n\nThe textbook way to demonstrate pass by value versus pass by reference is to write a `swap` method. In a language with true pass by reference (like C++ with reference parameters), a function can take two variables and swap the values stored in the caller's slots. In Java, this is not possible. Here's the attempt with primitives.\n\n\n```java\npublic class PrimitiveSwapAttempt {\n public static void main(String[] args) {\n int priceA = 30;\n int priceB = 50;\n swap(priceA, priceB);\n System.out.println(\"priceA = \" + priceA);\n System.out.println(\"priceB = \" + priceB);\n }\n\n static void swap(int a, int b) {\n int temp = a;\n a = b;\n b = temp;\n System.out.println(\"Inside swap: a = \" + a + \", b = \" + b);\n }\n}\n```\n\n\nInside `swap`, the local copies are exchanged. The caller's variables are untouched. This matches the primitive rules from earlier in the lesson, and it's the standard \"swap doesn't work\" demonstration.\n\nThe version where the rules might appear to change: swap with objects.\n\n\n```java\npublic class ProductSwapAttempt {\n public static void main(String[] args) {\n String productA = \"Wireless Mouse\";\n String productB = \"Laptop Stand\";\n swap(productA, productB);\n System.out.println(\"productA = \" + productA);\n System.out.println(\"productB = \" + productB);\n }\n\n static void swap(String a, String b) {\n String temp = a;\n a = b;\n b = temp;\n System.out.println(\"Inside swap: a = \" + a + \", b = \" + b);\n }\n}\n```\n\n\nSame result. The parameters `a` and `b` are local variables that received copies of the references. The method swaps the local copies. The caller's `productA` and `productB` still hold their original references and still point at the original strings. The swap was real inside the method's frame. It was invisible from the caller's frame.\n\nThis is the cleanest practical proof that Java is pass by value for reference types too. If references could be swapped through the parameter, this code would work. It doesn't.\n\nWhen swap behavior is actually needed in Java, design around it. One common pattern is to return the swapped pair (using an array or a small class). Another is to put both values inside a container object and mutate the container's fields, which works because mutation of a shared object is visible. There's no way to swap two independent local variables of the caller through a method call. The language mechanism doesn't allow it.\n\n---\n\n# Arrays Are References Too\n\nArrays are objects in Java, even arrays of primitives. So an `int[]` parameter follows the reference-type rules: the array reference is copied, but both variables point at the same array. Mutating an element is visible. Reassigning the parameter to a new array is not.\n\n\n```java\npublic class PriceUpdater {\n public static void main(String[] args) {\n int[] prices = {30, 50, 80};\n applyDiscount(prices);\n System.out.println(\"After applyDiscount:\");\n for (int p : prices) {\n System.out.println(p);\n }\n }\n\n static void applyDiscount(int[] arr) {\n for (int i = 0; i < arr.length; i++) {\n arr[i] = arr[i] - 10;\n }\n }\n}\n```\n\n\nThe method received a copy of the array reference. Writing into `arr[i]` writes into the one shared array. The caller's variable still points at that array and reads the updated values.\n\nCompare that to a version that tries to replace the whole array.\n\n\n```java\npublic class PriceReplacer {\n public static void main(String[] args) {\n int[] prices = {30, 50, 80};\n replace(prices);\n System.out.println(\"After replace:\");\n for (int p : prices) {\n System.out.println(p);\n }\n }\n\n static void replace(int[] arr) {\n arr = new int[]{1, 2, 3};\n System.out.println(\"Inside method: \" + arr[0] + \", \" + arr[1] + \", \" + arr[2]);\n }\n}\n```\n\n\n`arr = new int[]{1, 2, 3}` rebinds the local parameter. The caller's `prices` variable still holds its own reference, still pointing at `{30, 50, 80}`. Nothing in the caller changed, because the parameter was a separate slot the whole time.\n\nThis is the same distinction we saw with the cart: mutating the elements is visible, reassigning the parameter is not.\n\nReturning a new array from a method (and assigning it back at the call site) is one way to produce a \"replaced\" array without surprising the caller. The trade-off is the cost of allocating that new array, which for large arrays is the dominant work. For in-place updates of small arrays, in-place mutation is fine and avoids the allocation. Pick based on whether the caller expects a separate result or an updated input.\n\n---\n\n# Strings Look Strange, but the Rule Is the Same\n\nStrings are reference types, so by the rules above, mutating a `String` through a parameter should be visible to the caller, just like mutating a list. Yet code like this seems to behave like a primitive.\n\n\n```java\npublic class StringPuzzle {\n public static void main(String[] args) {\n String productName = \"Wireless Mouse\";\n upper(productName);\n System.out.println(\"Caller sees: \" + productName);\n }\n\n static void upper(String name) {\n name = name.toUpperCase();\n System.out.println(\"Inside method: \" + name);\n }\n}\n```\n\n\nThe caller's `productName` is unchanged, even though `String` is a reference type. What's going on?\n\nTwo things are stacked here, and both follow the rules already established:\n\n1. **`String` is immutable.** Once a `String` object exists, no method on it can change its characters. So `name.toUpperCase()` does not mutate the existing string. It builds and returns a new `String`.\n2. **The parameter is a separate slot.** The line `name = name.toUpperCase()` is reassigning the local parameter to point at the new `String`. By the reference-type rule, that reassignment is local to the method and the caller's variable is not affected.\n\nBecause `String` is immutable, there is no version of this code where the method could mutate the caller's string. The only way to \"change\" a string is to build a new one and reassign, and reassignment of a parameter is local. So even though `String` is technically a reference type, it appears to behave like a primitive when passed to a method. The behavior comes from immutability, not from a special pass-by-value rule for strings.\n\nCompare that to a mutable reference type. If `String` were mutable and had a method like `mutateToUpper()` that edited the characters in place, the caller would see the change. The list and array examples above show exactly that pattern with collections that do allow in-place mutation.\n\nThe story is consistent: the rule is \"pass by value of the reference\". Whether the caller sees a change depends on whether the shared object is mutated (visible) or the parameter is reassigned (not visible), and whether the type even allows mutation at all (`String` doesn't).\n\n---\n\n# Java vs. Other Languages, Briefly\n\nThis question comes up because some programming languages let a function receive a parameter and write through it to update the caller's variable. Those languages have an explicit feature called **pass by reference**, where the parameter is not a copy but is literally the same storage slot as the caller's variable. Reassigning the parameter rebinds the caller's variable. Setting the parameter to a new value changes what the caller sees.\n\nJava does not have this. Every parameter in Java is a fresh local variable that receives a copy of the argument's value. For primitives the value is the number. For objects the value is the reference. There is no syntax in Java that gives a method a way to rebind the caller's variable. No keyword (`final`, `static`, anything else) changes this. In a language that does have pass by reference, the difference is real and shows up exactly in the swap example: there, a swap function works; in Java, it doesn't, regardless of the types used.\n\nFamiliarity with those other languages isn't required to write Java. The relevant point is that \"pass by reference\" is a specific feature Java doesn't have, and using the term loosely causes the confusion when explaining Java's behavior with objects.\n\n---\n\n# How to Answer This in an Interview\n\nThis is a common conceptual question in a Java interview, and a clean answer demonstrates a real understanding of the mechanism rather than just pattern-matching the behavior.\n\nA good answer is something close to: **\"Java is pass by value. Always. For objects, what gets copied is the reference, not the object. So the method and the caller end up pointing at the same object, which is why mutating it through the parameter is visible to the caller, but reassigning the parameter is not.\"**\n\nThat answer does three things in two sentences: it states the rule, it explains why the two behaviors look different, and it draws the line between mutation and reassignment. Pairing it with the swap example demonstrates the ability to reason through the mechanism.\n\n**Avoid:**\n\n- \"Java is pass by reference for objects.\" This is incorrect.\n- \"Java is pass by value for primitives and pass by reference for objects.\" Same problem, restated.\n- \"It's complicated.\" It isn't.\n\n---\n\n# Putting It All Together\n\nOne worked example, three behaviors, all from the same rule.\n\n\n```java\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class PassByValueSummary {\n public static void main(String[] args) {\n int price = 100;\n String productName = \"Wireless Mouse\";\n List cart = new ArrayList<>();\n cart.add(productName);\n\n modifyAll(price, productName, cart);\n\n System.out.println(\"price = \" + price);\n System.out.println(\"productName = \" + productName);\n System.out.println(\"cart = \" + cart);\n }\n\n static void modifyAll(int amount, String name, List items) {\n amount = amount - 20;\n name = name.toUpperCase();\n items.add(\"Laptop Stand\");\n items = new ArrayList<>();\n items.add(\"Headphones\");\n }\n}\n```\n\n\nThree parameters, three different-looking outcomes, one consistent rule:\n\n- `amount` is a primitive copy. Subtracting 20 changes the copy. The caller's `price` is untouched, still `100`.\n- `name` is a copy of a reference. Reassigning the parameter to a new `String` (the result of `toUpperCase()`) is local. The caller's `productName` is untouched, still `\"Wireless Mouse\"`.\n- `items` starts out as a copy of the cart reference. The line `items.add(\"Laptop Stand\")` mutates the shared list, which is visible to the caller. Then `items = new ArrayList<>()` rebinds the local parameter, and `items.add(\"Headphones\")` adds to that new list, which the caller never sees. The caller's `cart` is now `[Wireless Mouse, Laptop Stand]`.\n\nTracing this example reinforces the rule: the parameter is a separate slot that starts with a copy. Operations through that slot (mutating the object the slot points at) are visible. Operations on the slot itself (reassigning it) are not.","pageType":"java"}

Pass by Value

Get Premium