Click here to Skip to main content
15,892,674 members
Articles / Web Development

Java and the Sweet Science

Rate me:
Please Sign up or sign in to vote.
5.00/5 (1 vote)
13 Oct 2014CPOL2 min read 8.5K   2   1
Java and the sweet science

When you have been developing in Java for 15 years and a coworker asks you to help him 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:

C#
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:

C#
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:

C#
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:

C#
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 Auto­boxing, thus the name of this article.

— Brad Mongar, asktheteam@keyholesoftware.com

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Keyhole Software
United States United States
Keyhole is a software development and consulting firm with a tight-knit technical team. We work primarily with Java, .NET, and Mobile technologies, specializing in application development. We love the challenge that comes in consulting and blog often regarding some of the technical situations and technologies we face. Kansas City, St. Louis and Chicago.
This is a Organisation

3 members

Comments and Discussions

 
GeneralAnother reason why implicit heavy type conversion is bad Pin
Chad3F16-Oct-14 16:07
Chad3F16-Oct-14 16:07 
I've never been a fan of such implicit type conversion, and this is another example.

Some other reasons are:

1) Hides inefficient code due to "easy" of use without knowing what's going on. Sometimes, which should be (and would have to be, if it got a compile error instead) written better. Imagine a tight loop where someone is adding a value to an Integer object (not int), potentially causing it to create hundreds, thousands, or even millions of temp objects. OMG | :OMG:

2) Obscures/breaks type-safe matching of method parameters.

I actually got burned by the second case once. I was calling a method for inserting an Integer into a collection, and transposed the object value and index arguments. Since the values could be auto-boxed/unboxed, it happily did so without any warning. And as a result it immediately didn't work as expected when run. Mad | :mad:

Even if auto-boxing a primitive to an object it always safe (assuming available memory), it is clearly not always safe to go the other direction, based on your article. I think that alone should have been reason enough to have never added such an auto conversion to the language. At least not without some input from the end developer (like requiring an auto-convert-allowed keyword/annotation/something hint on the variable declaration).

Anyway.. that's my rant.

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.