4 things to remember on autoboxing and unboxing

In the previous post Autoboxing and unboxing in java we have discussed that feature which is introduced in jdk 1.5. And we saw it is a very relevant and convenient feature for developers as the compiler is able to “box” and “unbox” automatically on requirements. Now we can look into some of the things to remember when autoboxing and unboxing.

1. Compare objects with .equals() method when autoboxed

As you know the “==” operator compares the references when we compare two objects, this can be an issue when two primitives are autoboxed and compared with “==” operator.

The scenario is explained in the following program which is to compare two Integer values.

The output we expect in the usual way may be “a and b are equal” but the actual output is a and b are not equal. It is because the int values a and b are “autoboxed” to their wrapper objects Integer which uses their object reference in the memory to compare when we use “==” operator.

So what do we need in situations like this? We can use the .equals() method in the Object as follows.

The output will be as we expected – a and b are equal.

2. Mixing primitive and wrapper in relational or equality operator

If we use a wrapper object to compare against a primitive using relational operator (like “<" or ">“) the unboxing of that wrapper can cause NullPointerException.

We can see the situation on running the below program.

Here the program actually tries to unbox the Integer> variable i which is not initialized and when it unboxes it throws NullPointerException as primitive variables cannot hold null values while wrapper objects can. So make sure you initialize wrapper objects with non null values before unboxes them. (Note: This section is added after Mr.Qing jun tian raised a comment in this post. Thank you for your suggestion Qing).

3. Performance hit

Frequent autoboxing and unboxing can create performance issues as the number of objects created will increase drastically and as jvm tries to Garbage collect those objects.

For example consider the following program.

Lets check what the compiler actually does with this code. First the statement count += 1; will be converted to count = count + 1;. The variable count is not a primitive type to do a + operation. So the compiler “unboxes” the wrapper object count to primitive type count and then does a + operation on it.

Now the incremented value (which is a primitive type) is assigned back to count which is a wrapper object. So compiler creates a new object for assigning it back to wrapper variable count. So the effective translation will be like

Which creates around 1000 Integer objects in the memory and those objects needs to be garbage collected; which can impact on the performance of your code.

4. Cached objects

From the last example we saw that java created new objects of Integer wrapper class when autoboxing. But still it caches values from -128 to +127 which can cause unexpected behavior when performing some operations on these objects. This problem is explained in more detail in the post problem of comparing Integer objects with == operator

So these are the things to remember while Autoboxing and unboxing in java. Please share your comments if I have missed something.

Leave a Comment

Your email address will not be published. Required fields are marked *