Why Java’s Ternary Operator Can Throw NullPointerException and How to Prevent It

Basic Review

The article starts by introducing the conditional (ternary) operator, its official name Conditional Operator ? : , and its syntax

<span><expression1> ? <expression2> : <expression3>

. It explains that the operator evaluates expression1 and returns either expression2 or expression3 without evaluating both.

Auto‑boxing and Auto‑unboxing

Java provides eight primitive types and corresponding wrapper classes. To ease usage of wrappers in object contexts, Java supports automatic boxing (primitive → wrapper) and unboxing (wrapper → primitive) via valueOf() and xxxValue() methods.

Problem Reproduction

A simple example demonstrates the NPE:

boolean flag = true; // ensure the second operand executes
boolean simpleBoolean = false;
Boolean nullBoolean = null;
boolean x = flag ? nullBoolean : simpleBoolean; // NPE at runtime

The compiled bytecode shows the compiler inserts an automatic unboxing call nullBoolean.booleanValue(), which throws NullPointerException. This behavior is independent of the JDK version (tested on JDK 6, 8, 14).

Principle Analysis

According to JLS 15.25, the type of a conditional expression is determined by the types of the second and third operands. If one operand is primitive T and the other is its boxed type, the result type is T, forcing the compiler to unbox the boxed operand. The rule is consistent across Java 7 and Java 8, but Java 8 adds more precise type inference for reference expressions, reducing unnecessary unboxing.

Examples of six common patterns illustrate when automatic unboxing occurs (e.g., boolean x3 = flag ? objectBoolean : simpleBoolean; leads to objectBoolean.booleanValue()), and why they can produce NPE when the boxed operand is null.

Extended Cases

When the second operand is a generic Map<String, Boolean> lookup, the expression becomes a reference conditional expression. In Java 8 the compiler can infer the result type as Boolean, avoiding unboxing; in Java 7 it cannot, so it inserts an unboxing step that may cause NPE.

Summary

To prevent NPE caused by automatic unboxing in ternary expressions, keep the types of the second and third operands consistent, and align the target variable’s type with them. Prefer using wrapper types throughout when possible and add unit tests to catch such issues.

Further Thinking

The article encourages readers to consider more complex scenarios, such as generic collections and version‑specific JLS nuances, to deepen their understanding of Java’s type system.