Booleans, conditional operators and autoboxing

Question

Why does this throw NullPointerException

public static void main(String[] args) throws Exception {
    Boolean b = true ? returnsNull() : false; // NPE on this line.
    System.out.println(b);
}

public static Boolean returnsNull() {
    return null;
}

while this doesn't

public static void main(String[] args) throws Exception {
    Boolean b = true ? null : false;
    System.out.println(b); // null
}

?

The solution is by the way to replace false by Boolean.FALSE to avoid null being unboxed to boolean --which isn't possible. But that isn't the question. The question is why? Are there any references in JLS which confirms this behaviour, especially of the 2nd case?

Solution 1

The difference is that the explicit type of the returnsNull() method affects the static typing of the expressions at compile time:

E1: `true ? returnsNull() : false` - boolean (auto-unboxing 2nd operand to boolean)

E2: `true ? null : false` - Boolean (autoboxing of 3rd operand to Boolean)

See Java Language Specification, section 15.25 Conditional Operator ? :

• For E1, the types of the 2nd and 3rd operands are Boolean and boolean respectively, so this clause applies:

  If one of the second and third operands is of type boolean and the type of the other is of type Boolean, then the type of the conditional expression is boolean.

  Since the type of the expression is boolean, the 2nd operand must be coerced to boolean. The compiler inserts auto-unboxing code to the 2nd operand (return value of returnsNull()) to make it type boolean. This of course causes the NPE from the null returned at run-time.

• For E2, types of the 2nd and 3rd operands are <special null type> (not Boolean as in E1!) and boolean respectively, so no specific typing clause applies (go read 'em!), so the final "otherwise" clause applies:

  Otherwise, the second and third operands are of types S1 and S2 respectively. Let T1 be the type that results from applying boxing conversion to S1, and let T2 be the type that results from applying boxing conversion to S2. The type of the conditional expression is the result of applying capture conversion (§5.1.10) to lub(T1, T2) (§15.12.2.7).

  • S1 == <special null type> (see §4.1)
  • S2 == boolean
  • T1 == box(S1) == <special null type> (see last item in list of boxing conversions in §5.1.7)
  • T2 == box(S2) == `Boolean
  • lub(T1, T2) == Boolean

  So the type of the conditional expression is Boolean and the 3rd operand must be coerced to Boolean. The compiler inserts auto-boxing code for the 3rd operand (false). The 2nd operand doesn't need the auto-unboxing as in E1, so no auto-unboxing NPE when null is returned.

---

This question needs a similar type analysis:

Java conditional operator ?: result type

Solution 2

The line:

    Boolean b = true ? returnsNull() : false;

is internally transformed to:

    Boolean b = true ? returnsNull().booleanValue() : false; 

to perform the unboxing; thus: null.booleanValue() will yield a NPE

This is one of the major pitfalls when using autoboxing. This behavior is indeed documented in 5.1.8 JLS

Edit: I believe the unboxing is due to the third operator being of boolean type, like (implicit cast added):

   Boolean b = (Boolean) true ? true : false; 

Solution 3

From Java Language Specification, section 15.25:

• If one of the second and third operands is of type boolean and the type of the other is of type Boolean, then the type of the conditional expression is boolean.

So, the first example tries to call Boolean.booleanValue() in order to convert Boolean to boolean as per the first rule.

In the second case the first operand is of the null type, when the second is not of the reference type, so autoboxing conversion is applied:

• Otherwise, the second and third operands are of types S1 and S2 respectively. Let T1 be the type that results from applying boxing conversion to S1, and let T2 be the type that results from applying boxing conversion to S2. The type of the conditional expression is the result of applying capture conversion (§5.1.10) to lub(T1, T2) (§15.12.2.7).

Comments

[Erick Robertson]

Why does it try to unbox like that, when the ultimate value is a Boolean object?

[BalusC]

This answers the first case, but not the second case.

[Erick Robertson]

Probably there is an exception for when one of the values is null.

[BalusC]

@Erick: does JLS confirm this?

[Erick Robertson]

Yes. It's in the next line in the link @axtavt provided. I updated the answer.

[axtavt]

@Erick: I don't think it's applicable since boolean is not a reference type.

[Jay]

And may I add ... this is why you should make both sides of a ternary the same type, with explicit calls if necessary. Even if you have the specs memorized and know what will happen, the next programmer to come along and read your code might not. In my humble opinion, it would be better if the compiler just produced an error message in these situations rather than doing things that are difficult for ordinary mortals to predict. Well, maybe there are cases where the behavior is truly useful, but I haven't hit one yet.

[BalusC]

Makes sense ... I think. The §15.12.2.7 is a pain.

[Bert F]

It's easy ... but only in hindsight. :-)

[Geek]

@BertF What does the function lub in lub(T1,T2) stand for?

[Bert F]

@Geek - lub() - least upper bound - basically the closest superclass that they have in common; since null (type "the special null type") can be implicitly converted (widened) to any type, you can consider the special null type to be a "superclass" of any type (class) for the purposes of lub().