Java introduced the concept of autoboxing and unboxing since JDK 5. It has been used quite liberally by developers ever since. But those that do not understand the difference between primitives and Wrapper types can end up misusing it. They can especially become dangerous when coupled with a framework that provides some sort of type mapping, such as entity EJBs that map Wrappers to table columns.

Let us look at some of the gotchas

Gotcha 1:

1
2
3
4
5
6
7
8
9

public static void main(String[] args) throws Exception
{
    Test test = new Test();
    int autobox = test.autobox();
}
private Integer autobox()
{
    return null;
}

What could possibly be the output of this program ? Well, let me not leave you guessing

1
2

Exception in thread "main" java.lang.NullPointerException
	at com.tests.Test.main(Test.java:4)

As a java programmer, when I see this exception stack trace I immediately think ‘Hmm… the test reference must have become null somehow’ without realizing that unboxing the null to a primitive failed. I could end up wasting time analyzing something that is perfectly all right, if I do not have a look at the autobox() method first.

Gotcha 2:
Lets write a method that will simply add to a counter

1
2
3
4
5
6
7
8
9
10
11

private void loopDeLoop()
{
    long past = System.nanoTime();
    Integer iCounter=0;
    for(iCounter=0; iCounter<1000000000;iCounter++)
    {
        iCounter++;
    }
    long now = System.nanoTime();
    System.out.println(now - past);
}

The execution time of this method is 8197883698 nanos. Convert the Integer iCounter in line 4 to int iCounter and the execution time drops to 509410924 nanos. That is a 16 fold decrease. The result will be more significant as this number increases.

Now if you are telling me no one is foolish enough to loop 1000000000 times to add a counter, think again. Errors / inefficiencies have a way of creeping into the system. Some one may not intentionally try to do this. But it can happen.

Gotcha 3:

Think of all the memory you are wasting by creating those extra objects. Everytime you do a ++ on an Integer you are creating a new one. Integers are immutable so you cannot assign a new value to it without actually creating a new object. This adds a silent memory overhead. Another side effect of this is that it makes you think Integer is actually mutable. Its not !

Gotcha 4:

When you map a potentially autoboxable element to say a database row and retrieve it in an unboxed fashion, KABOOM. You get the cryptic NullPointerException stated in Gotcha 1. The twist comes when (if) a framework tries to handle this exception. If the framework writes internal codegen and does not reveal the actual code written, good luck debugging this buddy

Gotcha 5:

Have a look at this code

1
2
3
4
5
6
7
8
9
10
11
12
13
14

interface Tearable
{
    public Integer tear();
}
 
class TearBoy implements Tearable
{
 
    @Override
    public int tear()
    {
        return 0;
    }
}

What happens when I have a reference to a Tearable interface that points to the concrete TearBoy class ? Nothing. You know why ? This code will not even compile. It looks a little deceptive because you would think that an Integer can by unboxed to int and the code would work. But autoboxing here would break the interface’s contract.

All that said, there have been times when the autoboxing / unboxing feature has saved some time. But it is easy to overlook the gotchas mentioned above and you could end up wasting time instead. Use autoboxing / unboxing judiciously and think about the side effects before you use it.