When you have been developing in Java for 15 years and a coworker asks you to help them debug a null pointer exception, you don’t expect to be surprised. Usually it is quite obvious what is null and the only thing you need to do is find out why.
Sometimes it is a little more difficult because someone has created a chain of dereferenced objects. The other day I ran into something a little new to me and baffling for a period of time. One of the easiest things to debug in Java was a momentary mystery.
Consider the code below and tell me where the Null Pointer Exception is:
return value;
That right, the NPE was being thrown on a simple return statement.
How could this be? There is no explicit dereferencing going on. No reference to be null. That statement is as simple as they come. Let me expand the code view a little bit for you to get a better idea of what is going on:
public int getValue(){
return value;
}Once again, we are looking at very simple code. Between the code above and the hint in the title of the article, you may have figured out what is going on or you may be more confused. Again nothing is being explicitly dereferenced. Not only that we aren’t even dealing with a reference, it is returning a primitive.
Have you figured it out from the clues yet? Okay, here is the rest of the code and the explanation:
package Example;
public
class Example {
Integer value;
public int getValue(){
return value;
}
}Notice that value is an Integer with a capital I and getValue return int.
In the old days before Java 5, you would have gotten a compile error on the above code. Java 5 however introduced Autoboxing. This feature has been around for almost half my Java career and had never stung or confused me. It has always been a convenient feature.
Autoboxing allows for seamless conversion between primitives and their first class object equivalents. So instead of calling value.intValue to get the primitive, you can just assign value. But under the covers it still calls the intValue method.
That is where the NPE happened. The line in question became:
return value.intValue();
On that line, it is obvious where the NPE happens.
Oh, in case anyone missed it, the sport boxing is called the Sweet Science. I felt like I had been sucker-punched by Autoboxing, thus the name of this article.
| Reference: | Java And The Sweet Science from our JCG partner Brad Mongar at the Keyhole Software blog. |
I’d had a similar problem with unboxing just recently. Here’s a slightly altered version of it someStream.filter(() -> !someBooleanMethod()).toList(); I was getting an NPE on the lambda in the filter method, and I couldn’t figure out why. After several rounds of debug tracing (it took me a while to decide to dig into someBooleanMethod(), since the lambda was the thing getting the error) and found out that the boolean generated inside the method was coming back null. The method signature returned the object type, so it wasn’t doing the NPE on the return statement, but rather in converting it to… Read more »
Thanks for your input. After hearing of similar problems from other people maybe I shouldn’t have been surprised by the NPE but surprised that I haven’t seen it more before. Whenever a new useful feature is added to the language or a framework, the benefits are often easy to recognize. It’s the gotchas that take a while to learn.