JDK-6586958 : Boxing conversion for the null type is unspecified
  • Type: Bug
  • Component: specification
  • Sub-Component: language
  • Affected Version: 6u1
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-07-30
  • Updated: 2014-02-26
  • Resolved: 2011-07-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 rcFixed
Related Reports
Relates :  
Description
J2SE Version (please include all output from java -version flag):
java version "1.6.0_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing)

Does this problem occur on J2SE 5.0.x or 6.0?  Yes / No (pick one)
Yes

Operating System Configuration Information (be specific):
Microsoft Windows XP [Version 5.1.2600]

Bug Description:
RFE: Replace conditional of primitive and object to use boxing instead of unboxing

Currently using the conditional operator on a primitive and object can be very error prone.
The code below will throw a NullPointerException.
If boxing was used instead of unboxing we would not have this problem.
(Bug Report 6303028 looks like they are asking for the same things)

Workaround: box the primitives ourselves (ie in the case below use Integer c = a ? new Integer(1) : b ? new Integer(2) : null; instead)

public class Test {
  public static void main(String[] args) {
    boolean a = false;
    boolean b = false;
    Integer c = a ? 1 : b ? 2 : null;
  }
}

Comments
EVALUATION Consider the code below. Given int and the null type, the conditional has the type lub(box(int),box(NullType)) which is Integer: boolean a = false; boolean b = false; ... a ? 1 : null ... The result of applying boxing conversion to the null type is unspecified. Pragmatically, the result is the null type. This oversight is why I am accepting the CR. For 'a ? 1 : (b ? 2 : null)', the second and third operands are int and Integer respectively. The general approach now is binary numeric promotion, which statically results in int. The unboxing performed by b.n.p. causes an NPE on the runtime value of 'b ? 2 : null'. The fact that this value is null is irrelevant to the compiler, which can only implement a rule to perform unboxing or boxing conversion. We made the rule be that b.n.p. performs unboxing conversion, because it was the most compatible course of behavior. It is true that 'a ? new Integer(..) : b ? new Integer(..) : null' gives a different result, but this is just the way things have to be. 'b ? new Integer(..) : null' still has the type Integer, but now the conditional on 'a' has Integer in its second and third operands, so no binary numeric promotion is required.
30-07-2007