What is Autoboxing in Java?
Learn what autoboxing and unboxing mean in Java, why they exist for generics, and common pitfalls like the Integer cache and null unboxing NPEs.
Expected Interview Answer
Autoboxing is the compiler's automatic conversion of a primitive value into its corresponding wrapper object (e.g. int to Integer), and unboxing is the reverse conversion from a wrapper back to a primitive, both inserted transparently by the compiler at compile time.
Autoboxing exists so primitives can be used wherever an object is required, such as in generic collections like List<Integer> which cannot hold raw int values. Under the hood, boxing an int calls Integer.valueOf(int), and unboxing an Integer calls its intValue() method. A subtle trap is that Integer.valueOf caches values from -128 to 127, so == comparisons on boxed values in that range appear to work by reference equality but silently break outside it. Another trap is unboxing a null wrapper, which throws NullPointerException, and autoboxing inside tight loops or comparisons can also introduce unexpected object allocation overhead compared to using primitives directly.
- Lets primitives be stored in generic collections like List<Integer>
- Removes boilerplate manual wrapping/unwrapping in most code
- Keeps primitive-based and object-based APIs interoperable
- Enables primitives to participate in object-oriented APIs seamlessly
- Understanding it helps avoid subtle == and NPE bugs
AI Mentor Explanation
Autoboxing is like a raw run tally being automatically stamped onto an official player card so it can be filed in the same folder as other player records without a clerk doing it by hand. Unboxing is the reverse, pulling that number back off the card to use in a live scoreboard calculation, and the caching trap is like the pavilion keeping pre-printed cards only for small, common scores.
Step-by-Step Explanation
Step 1
Compiler inserts boxing automatically
Assigning an int to an Integer variable triggers an implicit Integer.valueOf(int) call, no manual wrapping needed.
Step 2
Compiler inserts unboxing automatically
Using an Integer where an int is expected triggers an implicit call to intValue().
Step 3
Understand why it's needed
Generics like List<Integer> require object types, so autoboxing bridges primitives into the generics/collections world.
Step 4
Watch the Integer cache trap
Integer.valueOf caches -128 to 127, so == comparisons on boxed values in that range accidentally 'work' but fail outside it.
Step 5
Guard against null unboxing
Unboxing a null wrapper reference throws NullPointerException, so check for null or use primitives where nullability isn't needed.
What Interviewer Expects
- Defines autoboxing and unboxing precisely with the underlying method calls
- Explains why autoboxing exists (generics/collections requiring objects)
- Knows the Integer cache range and its effect on ==
- Knows unboxing null throws NullPointerException
- Recommends using .equals() instead of == for boxed value comparison
Common Mistakes
- Using == to compare boxed Integer values expecting value equality universally
- Not realizing the Integer cache only covers -128 to 127
- Unboxing a possibly-null wrapper without a null check, causing NPE
- Assuming autoboxing has zero performance cost in hot loops
- Confusing autoboxing with generic type erasure, a separate concept
Best Answer (HR Friendly)
“Autoboxing is Java automatically converting a simple number or boolean into its object form (and back again) so it can be used in places that require objects, like lists. It's convenient, but it can hide subtle bugs, like comparing two boxed numbers with == instead of properly checking their actual values.”
Code Example
Integer a = 100;
Integer b = 100;
System.out.println(a == b); // true - both cached (-128 to 127)
Integer c = 200;
Integer d = 200;
System.out.println(c == d); // false - outside cache range, different objects
System.out.println(c.equals(d)); // true - correct way to compare values
List<Integer> nums = new ArrayList<>();
nums.add(5); // autoboxing: int -> Integer
int first = nums.get(0); // unboxing: Integer -> intFollow-up Questions
- Why does Integer caching cause == to behave inconsistently?
- What exception occurs when unboxing a null wrapper, and why?
- How does autoboxing interact with Java generics and type erasure?
- Is there a performance cost to autoboxing in tight loops?
- Which wrapper classes have caching behavior similar to Integer?
MCQ Practice
1. What method does the compiler call when autoboxing an int into an Integer?
Autoboxing uses Integer.valueOf(int), which may return a cached instance for small values.
2. What is the cached range for Integer.valueOf?
The JVM caches Integer objects for values from -128 to 127 by default, affecting == comparisons in that range.
3. What happens when unboxing a null Integer to a primitive int?
Unboxing calls intValue() on the reference; calling a method on null throws NullPointerException.
Flash Cards
What is autoboxing? — The compiler's automatic conversion of a primitive into its wrapper object, e.g. int to Integer.
What method underlies unboxing an Integer? — intValue(), called implicitly wherever a primitive int is required.
What is the Integer cache trap? — Integer.valueOf caches -128 to 127, so == works by luck in that range but fails outside it.
How should boxed wrapper values be compared? — With .equals(), not ==, to compare actual values rather than object identity.