I\'m a bit puzzled about the conditional operator. Consider the following two lines:
Float f1 = false? 1.0f: null;
Float f2 = false? 1.0f: false? 1.0f: null;
The difference is static typing of the expressions at compile time:
E1: `(false ? 1.0f : null)`
- arg 2 '1.0f' : type float,
- arg 3 'null' : type null
- therefore operator ?: : type Float (see explanation below)
- therefore autobox arg2
- therefore autobox arg3
E2: `(false ? 1.0f : (false ? 1.0f : null))`
- arg 2 '1.0f' : type float
- arg 3 '(false ? 1.0f : null)' : type Float (this expr is same as E1)
- therefore, outer operator ?: : type float (see explanation below)
- therefore un-autobox arg3
Here's my understand from reading through the spec and working backwards from the result you got. It comes down to the type of the third operand of the f2 inner conditional is null type while the type of the third operand of the f2 outer conditional is deemed to be Float.
Note: Its important to remember that the determination of type and the insertion of boxing/unboxing code is done at compile-time. Actual execution of boxing/unboxing code is done at run-time.
Float f1 = (false ? 1.0f : null);
Float f2 = (false ? 1.0f : (false ? 1.0f : null));
The f1 conditional and the f2 inner conditional: (false ? 1.0f : null)
The f1 conditional and the f2 inner conditional are identical: (false ? 1.0f : null). The operand types in the f1 conditional and the f2 inner conditional are:
type of second operand = float
type of third operand = null type (§4.1)
Most of the rules in §15.25 are passed up and this final evaluation is indeed 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).
S1 = float
S2 = null type
T1 = Float
T2 = null type
type of the f1 and f2 inner conditional expressions = Float
Since for f1, the assignment is to a Float reference variable, the result of the expression (null) is successfully assigned.
For f2 outer conditional: (false ? 1.0f : [f2 inner conditional])
For the f2 outer conditional, the types are:
type of second operand = float
type of third operand = Float
Note the difference in operand types compared to the f1/f2 inner conditionals that reference the null literal directly (§4.1). Because of this difference of having 2 numeric-convertible types, this rule from §15.12.2.7 applies:
Otherwise, if the second and third operands have types that are convertible (§5.1.8) to numeric types, then there are several cases: ...
- Otherwise, binary numeric promotion (§5.6.2) is applied to the operand types, and the type of the conditional expression is the promoted type of the second and third operands. Note that binary numeric promotion performs unboxing conversion (§5.1.8) and value set conversion (§5.1.13).
Because of the unboxing conversion performed on the result of the f2 inner conditional (null), a NullPointerException is raised.
I think rewriting the code makes the explanation clearer:
float f = 1.0f;
Float null_Float = false? f : null; // float + null -> OK
Float null_Float2 = false? (Float)f : null_Float; // Float + Float -> OK
Float npe = false? f : null_Float; // float + Float -> NPE
Thus the NPE is when we try to do something like:
Float npe = false? 1.0f : (Float)null;
To be or not to be, that is the question. :)
Edit: Actually, looking closer it seems that this case is actually a mix between the Hamlet (ternary operator and wrapped integral types) and the Elvis (auto-unboxing null) puzzlers. In any case, I can only recommend watching the video, it is very educational and enjoyable.
The following will throw a NPE as you attempt assign a null to a primitive
float f1 = false ? 1.0f: null;
That I believe is whats causing the NPE in the second statement. Because the first ternary returns a float for true it attempts to convert the false to a float as well.
The first statement will not convert to null as the required result is a Float
This for example this would not throw a NPE as its no longer needs to convert to primitive
Float f = false? new Float(1.0f): true ? null : 1.0f;
It looks like the JVM tries to unbox the second null to float instead of Float, thus NullPointerException. Hit it myself once. My take is that the second if does it because the true part of the first if evaluates as a float, not a Float.
After giving it a second thought, I think this a way of Java telling you that you are doing something strange. Just don't nest ternary ifs and you will be fine :-)