Unboxing a null boxed object throws unexpected NullPointerException

Question

If you run the following code,

public class Foo{
    public static void main(String[] args){
        int id = new Bar().getId(); // throws unexpected NullPointerException
    }

    private static class Bar{
        private final Integer id;

        public Bar(){
            this(null);
        }

        public Bar(Integer id){
            this.id = id;
        }

        public Integer getId(){
            return id;
        }
    }
}

you will get the following stacktrace,

Exception in thread "main" java.lang.NullPointerException
    at Foo.main(Foo.java:3)

How come there's no compiler warning or anything? IMHO it's a pretty nasty subtlety with unboxing, or maybe I'm just naive.

---

Adding on to the answer provided by @Javier, if you're using Eclipse, you need to do the following to enable this:

1. Navigate to Window > Preferences > Java > Compiler > Errors/Warnings
2. Expand Potential programming problems
3. Toggle Boxing and unboxing conversions to either "Warning", or "Error"
4. Tap "OK"

Solution 1

I don't know what IDE are you using, but Eclipse has an option to enable warning on boxing and unboxing conversions. It is not possible to detect it as a null pointer access, since null is not immediatly unboxed, but via Bar.getId().

The expression of type Integer is unboxed into int
Foo.java line 3

Solution 2

If you try to use any method on a null or do anything that does not make sense with a null, it throws a NullPointerException.

Autounboxing is implemented with the [Integer object].intValue() method (or similar), so it throws a NullPointerException because you can't have null invoke a method.

Hope this helps!

Solution 3

it appears that this behavior is documented in the JDK™ 5.0 Documentation,

..you can largely ignore the distinction between int and Integer, with a few caveats. An Integer expression can have a null value. If your program tries to autounbox null, it will throw a NullPointerException.

Comments

[mre]

I've been using Eclipse for ~3 years and I didn't know that! Sweet!

[mre]

i did not say the exception was unreasonable, i said it was unexpected, especially since my IDE chose to ignore it by default.

[AgilePro]

OK, I was trying to get around what is "expected" and "unexpected". It is a run-time exception, not something that can be necessarily determined from static analysis. How would you expect the IDE to behave in this situation?

[mre]

I expected the IDE to at least warn me by default. Like I said, I think it's a pretty subtle runtime exception.

[AgilePro]

You would expect it to determine all the situations where you might get a run time NPE? This strikes me as running up against Gödel's theorem. But I recommend avoiding the Integer class when you don't need it.

[mre]

No, you're being hyperbolic. I would not expect it to account for all scenarios. But it looks like others were thinking the same since Eclipse provides such functionality when it comes to boxing/unboxing.

[AgilePro]

Sorry about going hyperbolic, you are right. So the warning you want is simply that it is doing an inline type cast from an Integer to an int? I guess Eclipse can do that for you as a warning.

[Kyle]

It's annoying that eclipse can't turn on unboxing warnings without boxing! bugs.eclipse.org/bugs/show_bug.cgi?id=163065