Why does the Java compiler sometimes allow the unboxing of null?

Question

For example:

int anInt = null;

fails at compile time but

public static void main(String[] args) {
  for (int i = 0; i < 10; i++) {
    System.out.println("" + getSomeVal());
  }
}
public static int getSomeVal() {
   return new Random().nextBoolean() ? 1 : null;
}

fails (usually) at run time. Trying to return just null will also result in a compile error, so I assume there is something about having multiple paths that causes the compiler to infer that null is potentially an autoboxed int? Why can javac not fail to compile both cases with the same error?

score 20 · Accepted Answer · edited Aug 10 '12 at 10:57

20

In the first case, the compiler knows that you're trying to unbox a compile-time constant of null.

In the second case, the type of the conditional expression is Integer, so you're effectively writing:

Integer tmp = new Random().nextBoolean() ? 1 : null;
return (int) tmp;

... so the unboxing isn't happening on a constant expression, and the compiler will allow it.

If you changed it to force the conditional expression to be of type int by unboxing there, it would fail:

// Compile-time failure
return new Random().nextBoolean() ? 1 : (int) null;

edited Aug 10 '12 at 10:57

phihag

278,196
72
453
469

answered Aug 10 '12 at 08:23

Jon Skeet

1,421,763
867
9,128
9,194

The first case involves a null "type" being implicitly cast to an int type, resulting in a compiler error. The second case implicitly casts null to the left hand variable type, which is the type of the expression rather than the return value. I guess a careful reading of JLS 15.25 "If the second and third operands have the same type (which may be the null type), then that is the type of the conditional expression." gives you this, as the java compiler cannot give null a type of int and so is forced to use Integer for both by unboxing the 1. Very clear answer, thanks. – MilesHampson Aug 10 '12 at 09:50

score 2 · Answer 2 · edited Aug 10 '12 at 10:37

Boxing partially hides the distinction between primitives and corresponding wrapper objects, but it doesn't remove it.

There are two distinctions which are not changed by boxing:

objects can be null, while primitives cannot
objects have both state and identity, while primitives have only state (the value)

Occasionally, these differences can cause problems when using boxing.

Some points to remember :

be careful with nulls. Auto-unboxing a null object will cause a NullPointerException.
comparing items with == and equals must be done with care.

score 1 · Answer 3 · answered Aug 10 '12 at 08:33

You can't assign null to an int

    int anInt = null;

Java allows this since you are not assigning null to an int

    System.out.println("" + getSomeVal()); //null was just converted to a srting and was printed

If you perform this, you can get the error

    int anInt = getSomeVal();

Why does the Java compiler sometimes allow the unboxing of null?

3 Answers3

Linked