How can a ternary expression throw a NullPointerException even though neither branch is dereferenced? Explain the Integer/int unboxing trap.

## The setup Java has two parallel worlds for numbers: **primitives** (`int`, `long`, `boolean`, …) which are raw values, and **wrapper classes** (`Integer`, `Long`, `Boolean`, …) which are *objects* that hold one of those values and can also be `null`. **Autoboxing** is the compiler automatically converting a primitive to its wrapper (`int`→`Integer`); **auto-unboxing** is the reverse (`Integer`→`int`), which the compiler implements by inserting a call like `theInteger.intValue()`. A `null` reference has no `intValue()` to call, so **unboxing a `null` wrapper throws `NullPointerException`**. ## Why the ternary forces unboxing A ternary expression must have **one result type**, computed at compile time from both branches. When one branch is a primitive and the other is the matching wrapper, the JLS rules apply **binary numeric promotion**, which operates on *primitives*. To do that, the wrapper branch must be **unboxed** to its primitive first. So the compiler rewrites: ```java Integer boxed = null; int result = cond ? 0 : boxed; ``` roughly into: ```java int result = cond ? 0 : boxed.intValue(); // boxed.intValue() -> NPE if boxed is null ``` The whole expression's type is `int`, so the `Integer` branch is unboxed. If `boxed` is `null` **and that branch is taken**, you get an NPE that points at a line where you never wrote `.intValue()`. ## The extra-nasty variant Because the *type* is fixed for the whole expression, the unboxing conversion is part of the expression's shape. In practice the unboxing throws when the **null branch is evaluated**. The truly surprising cases are the ones where you did not even realize a wrapper was involved: ```java Map<String, Boolean> flags = new HashMap<>(); // flags.get("x") returns Boolean, and returns null for a missing key boolean on = someCond ? flags.get("x") : false; ``` Here `flags.get("x")` is a `Boolean`. The other branch is the primitive `false` (`boolean`). The result type is `boolean`, so the `Boolean` branch is unboxed. If the key is missing, `get` returns `null`, unboxing throws **NullPointerException**, and the line looks completely innocent. ## Why people miss it 1. There is **no visible dereference** — no `.` you typed. 2. It can be hidden behind generics (`Map<…, Integer>`, `Optional`-less getters, ORM fields typed as `Integer`). 3. It depends on *both* branches' static types, not on the value you think you are returning. ## How to avoid it - **Keep both branches the same reference type.** `cond ? Integer.valueOf(0) : boxed` keeps the result type `Integer`, so **no unboxing happens** and you safely get a (possibly null) `Integer` — no NPE at the ternary (you defer the null handling). - **Guard the null explicitly** before unboxing: `int r = (boxed != null) ? boxed : 0;` — now both branches are effectively `int` but you have ensured the wrapper is non-null on the branch that unboxes. - **Be deliberate about the target type.** If you want a primitive result, make sure every branch can produce a non-null value. - **Watch wrapper-returning APIs** (`Map.get`, JDBC/ORM nullable columns, parsed JSON) inside ternaries. ## Mental checklist for a ternary 1. Are the two branches different types? 2. Is one a primitive and one a wrapper? 3. If so, the wrapper **will be unboxed** — can it be `null`? If yes, you have a latent NPE. This is one of the most common 'looks fine, NPEs in production' Java bugs, which is why it is asked about often.