Given Java's pass-by-value semantics, what API-design and safety practices follow? When do you need defensive copying, and how does immutability change the calculus?

## The root cause Java is pass-by-value, so a method never reseats your variables — but for reference types, the *value passed is the reference*, and caller and callee end up holding references to the **same heap object**. Combined with mutability, this creates **aliasing**: two parts of the program can reach and modify one object without either knowing about the other. Aliasing of mutable state is the source of the hazards below. ## Hazard 1 — capturing a mutable argument ```java class Period { private final Date start, end; Period(Date start, Date end) { this.start = start; this.end = end; } // BUG } Date s = new Date(), e = new Date(); Period p = new Period(s, e); e.setTime(0); // the caller still holds e and can mutate Period's internals! ``` The constructor stored the *same* `Date` the caller holds. Because the caller still references it, the caller can mutate `Period`'s state after construction, breaking any invariant (e.g., start ≤ end). **Fix — defensive copy on input:** ```java this.start = new Date(start.getTime()); this.end = new Date(end.getTime()); ``` Copy *before* validating, and validate the copy, to avoid TOCTOU races with another thread mutating the original between check and copy. ## Hazard 2 — leaking a mutable field ```java Date getStart() { return start; } // BUG: caller can mutate internal Date ``` Returning the live field hands callers a reference to internal state. **Fix — defensive copy on output:** ```java Date getStart() { return new Date(start.getTime()); } ``` For collections, return an unmodifiable view or a copy: `List.copyOf(items)` or `Collections.unmodifiableList(...)`. ## How immutability dissolves the problem If the object **cannot be mutated**, aliasing is harmless: sharing the same reference is perfectly safe because no one can change it. So for immutable types you **skip all defensive copies**. This is why *minimize mutability* is a core Effective Java item. Immutable objects: - are **inherently thread-safe** (no synchronization needed), - can be **freely shared and cached** (and interned, like String literals), - make **safe map keys** (their hashCode can't drift), - simplify reasoning (no spooky action at a distance). Replacing `Date` with the immutable `java.time` types (`Instant`, `LocalDate`) removes the `Period` problem entirely — no copies needed. ## A decision rubric - **Argument is immutable** (String, boxed primitive, record-of-immutables, `Instant`): store/return directly, no copy. - **Argument is mutable and you store it** (`Date`, array, `ArrayList`): defensive-copy on the way in. - **Field is mutable and you expose it**: defensive-copy on the way out, or expose an unmodifiable view, or expose only immutable projections. - **You truly want shared mutable state** (rare, deliberate): document the ownership/contract explicitly and consider synchronization. ## Trade-offs and scale - **Allocation cost.** Defensive copies create garbage; in hot paths this matters. Immutability can also churn (copy-on-write), so for big aggregates consider persistent/structural-sharing structures or a clearly documented mutable core behind an immutable facade. - **Consistency over heroics.** Scattering manual copies is error-prone; prefer immutable-by-default value types and unmodifiable collections as the team norm, so the safe path is the default path. - **Arrays are always mutable** and have no immutable variant — wrap them (`List.of`/`copyOf`) or copy (`clone()`/`Arrays.copyOf`) at boundaries. ## Why this is the principal-level framing The junior fact ('Java is pass-by-value') becomes, at the architecture level, a policy: *control aliasing of mutable state at trust boundaries, and prefer immutability so the boundaries mostly vanish.* That policy is what keeps large codebases free of action-at-a-distance bugs and unnecessary synchronization.