Why Do We Use Autoboxing and Unboxing in Java

Why do we use autoboxing and unboxing in Java?

Some context is required to fully understand the main reason behind this.

Primitives versus classes

Primitive variables in Java contain values (an integer, a double-precision floating point binary number, etc). Because these values may have different lengths, the variables containing them may also have different lengths (consider float versus double).

On the other hand, class variables contain references to instances. References are typically implemented as pointers (or something very similar to pointers) in many languages. These things typically have the same size, regardless of the sizes of the instances they refer to (Object, String, Integer, etc).

This property of class variables makes the references they contain interchangeable (to an extent). This allows us to do what we call substitution: broadly speaking, to use an instance of a particular type as an instance of another, related type (use a String as an Object, for example).

Primitive variables aren't interchangeable in the same way, neither with each other, nor with Object. The most obvious reason for this (but not the only reason) is their size difference. This makes primitive types inconvenient in this respect, but we still need them in the language (for reasons that mainly boil down to performance).

Generics and type erasure

Generic types are types with one or more type parameters (the exact number is called generic arity). For example, the generic type definition List<T> has a type parameter T, which can be Object (producing a concrete type List<Object>), String (List<String>), Integer (List<Integer>) and so on.

Generic types are a lot more complicated than non-generic ones. When they were introduced to Java (after its initial release), in order to avoid making radical changes to the JVM and possibly breaking compatibility with older binaries, the creators of Java decided to implement generic types in the least invasive way: all concrete types of List<T> are, in fact, compiled to (the binary equivalent of) List<Object> (for other types, the bound may be something other than Object, but you get the point). Generic arity and type parameter information are lost in this process, which is why we call it type erasure.

Putting the two together

Now the problem is the combination of the above realities: if List<T> becomes List<Object> in all cases, then T must always be a type that can be directly assigned to Object. Anything else can't be allowed. Since, as we said before, int, float and double aren't interchangeable with Object, there can't be a List<int>, List<float> or List<double> (unless a significantly more complicated implementation of generics existed in the JVM).

But Java offers types like Integer, Float and Double which wrap these primitives in class instances, making them effectively substitutable as Object, thus allowing generic types to indirectly work with the primitives as well (because you can have List<Integer>, List<Float>, List<Double> and so on).

The process of creating an Integer from an int, a Float from a float and so on, is called boxing. The reverse is called unboxing. Because having to box primitives every time you want to use them as Object is inconvenient, there are cases where the language does this automatically - that's called autoboxing.

How does auto boxing/unboxing work in Java?

When in doubt, check the bytecode:

Integer n = 42;

becomes:

0: bipush        42
2: invokestatic  #16                 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
5: astore_1      

So in actuality, valueOf() is used as opposed to the constructor (and the same goes for the other wrapper classes). This is beneficial since it allows for caching, and doesn't force the creation of a new object on each boxing operation.

The reverse is the following:

int n = Integer.valueOf(42);

which becomes:

0: bipush        42
2: invokestatic  #16                 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
5: invokevirtual #22                 // Method java/lang/Integer.intValue:()I
8: istore_1      

i.e. intValue() is used (again, it's analogous for the other wrapper types as well). This is really all auto(un)boxing boils down to.

You can read about boxing and unboxing conversions in JLS §5.1.7 and JLS §5.1.8, respectively.

What is difference between wrapper and Auto Boxing/Unboxing in java?

Auto-boxing and auto-unboxing is just the compiler silently helping you create and use primitive wrapper objects.

For example, the int primitive type has wrapper class called Integer. You wrap and unwrap as follows:

int myInt = 7;

// Wrap the primitive value
Integer myWrappedInt = Integer.valueOf(myInt);

// Unwrap the value
int myOtherInt = myWrappedInt.intValue();

With auto-boxing and auto-unboxing, you don't have to do all that boiler-plate stuff:

int myInt = 7;

// Wrap the primitive value
Integer myWrappedInt = myInt; // Compiler auto-boxes

// Unwrap the value
int myOtherInt = myWrappedInt; // Compiler auto-unboxes

It's just a syntactic sugar, handled by the compiler. The generated byte code is the same.

Quick autoboxing/auto-unboxing question in Java

Your understanding is correct.

People starting confusing Integer and int when autoboxing was introduced in Java 5 in 2004. Previous to that, you had to box and unbox explicitly. Autoboxing has advantages of more succinct code but also disadvantages that some novice programmers don't realise exactly what is happening and unwittingly write code that needlessly boxes and unboxes.

By the way, your example of new Integer(2) is better coded as Integer.valueOf(2). The latter will use a cached object instead of creating a new one.

When using == for a primitive and a boxed value, is autoboxing done, or is unboxing done

It is defined in the JLS #15.21.1:

If the operands of an equality operator are both of numeric type, or one is of numeric type and the other is convertible (§5.1.8) to numeric type, binary numeric promotion is performed on the operands (§5.6.2).

And JLS #5.6.2:

When an operator applies binary numeric promotion to a pair of operands, each of which must denote a value that is convertible to a numeric type, the following rules apply, in order:

• If any operand is of a reference type, it is subjected to unboxing conversion
  [...]

So to answer your question, the Integer is unboxed into an int.

What are the strategies for catching unboxing and autoboxing issues at compile time?

The JRE / Compiler does something called Auto Unboxing - which is designed to save developer time when it comes to activities like this.

Autoboxing is the automatic conversion that the Java compiler makes between the primitive types and their corresponding object wrapper classes. For example, converting an int to an Integer, a double to a Double, and so on. If the conversion goes the other way, this is called unboxing.

https://docs.oracle.com/javase/tutorial/java/data/autoboxing.html

Edit: you might want to read this re your point on null objects - looks like a runtime error NullPointerException will be thrown, but you can setup most IDE's to warn about auto unboxing at compile time to help you either:

a) Make sure you have the right exception handling or;

b) Make sure you are not relying on the behaviour at all (always calling the method to get the primitive value)

---

Related Topics