What Actually Happened?#

Java’s conditional operator has the form condition ? valueIfTrue : valueIfFalse. Before assigning its result, the compiler determines a common type for the second and third operands.

Here is the surprising part: when one operand is a primitive int and the other is an Integer, Java can treat the expression as an int expression. That requires unboxing the Integer. If the selected Integer is null, the generated behavior is effectively a call to .intValue() on null, which immediately throws an NPE.

The type of the variable receiving the result does not prevent this. Even if the result is assigned to an Integer, the unboxing has already happened inside the ternary expression.

Case 1: The Trap—Primitive and Wrapper#

1
import java.util.Objects;
2

3
public class HelloDemo {
4
    public static void main(String[] args) {
5
        User user = new User(); // user.getA() returns null
6
        String a = "1";
7
        int c = 1; // Primitive int triggers unboxing of the other operand
8

9
        Integer b = Objects.equals(a, "2") ? c : user.getA();
10

11
        System.out.println(b);
12
    }
13

14
    static class User {
15
        Integer getA() {
16
            return null;
17
        }
18
    }
19
}

The condition is false, so Java evaluates user.getA(). Because the other operand is the primitive int variable c, Java tries to unbox the returned value:

1
user.getA().intValue()

Since user.getA() returns null, the program throws a NullPointerException before the result can be assigned to b.

Case 2: The Fix—Wrapper and Wrapper#

1
import java.util.Objects;
2

3
public class HelloDemo {
4
    public static void main(String[] args) {
5
        User user = new User(); // user.getA() returns null
6
        String a = "1";
7
        Integer c = 1; // Both operands are Integer references
8

9
        Integer b = Objects.equals(a, "2") ? c : user.getA();
10

11
        System.out.println(b);
12
    }
13

14
    static class User {
15
        Integer getA() {
16
            return null;
17
        }
18
    }
19
}

This time, both possible values are Integer references. The expression can therefore produce an Integer without unboxing the selected value.

Output:

1
null

Another Safe Option: Handle Null Explicitly#

Changing both operands to wrapper types is useful when null is a valid result. If the rest of the code expects a primitive, however, it is usually clearer to choose an explicit fallback:

1
Integer onlineStatus = devBaseVO.getOnlineStatus();
2
int status = condition
3
    ? 1
4
    : Objects.requireNonNullElse(onlineStatus, 0);

This makes the intended behavior visible: a missing online status becomes 0. If null indicates invalid state instead, fail with a more descriptive message:

1
int status = condition
2
    ? 1
3
    : Objects.requireNonNull(
4
        devBaseVO.getOnlineStatus(),
5
        "Online status must not be null"
6
    );

The Key Takeaway#

When a ternary expression mixes a primitive with its wrapper type, do not assume the wrapper can safely remain null. Check the type Java gives the entire expression and remember that unboxing occurs before assignment.

To avoid this trap:

• Use wrapper types on both sides when null is a valid result.
• Provide an explicit default when the result must be a primitive.
• Validate nullable values before using them in mixed primitive-wrapper expressions.

A tiny type difference—int versus Integer—can be the difference between printing null and throwing an exception.