What Are Wrapper Classes and Why Does Java Need Them?

A wrapper class wraps a primitive in an object: Integer for int, Double for double, Boolean for boolean, and so on for all eight primitives plus the two special cases Character and Void. Each wrapper is a final class with a single private field holding the primitive value.

They exist for three reasons. First, generics cannot be instantiated with primitives — the type argument List<Integer> is legal, List<int> is not, so anything that must live inside a collection, a stream or an Optional needs a wrapper. Second, the class library predates generics and had to support objects, so APIs like the older collection classes were designed around wrappers. Third, wrappers carry behaviour that primitives cannot: Integer.parseInt, Integer.toBinaryString, Character.isDigit, Boolean.parseBoolean and the value-comparison methods all live on the wrapper.

Where you should prefer the primitive: fields, method parameters and return types on hot paths. A wrapper is a heap object, so a field of type Integer holds a reference that must be dereferenced, may be null, and adds garbage-collection pressure. A field of type int holds the value inline with no reference and no null possibility.

Where you should prefer the wrapper: generic containers, optional values, and APIs that demand an object type. The recurring trap is that a wrapper can be null while a primitive cannot, and any operation that unboxes a null wrapper throws a NullPointerException at the point of use, often far from where the null was introduced.

Java gives you two ways in each direction. Explicit boxing uses the static factory Integer.valueOf(int), which returns a cached instance for small values. Explicit unboxing calls intValue(). The implicit forms — assigning an int to an Integer variable, or an Integer to an int variable — are compiler-inserted conversions that do exactly the same thing.

The unboxing of null is the failure everybody meets once. The compiler inserts a call to intValue() on the wrapper, and calling a method on a null reference throws NullPointerException. The compiler will not stop you, because a null wrapper is a perfectly legal value of the type.

public class Main {
    public static void main(String[] args) {
        int primitive = 42;
        Integer wrapper = Integer.valueOf(primitive);   // explicit boxing
        int back = wrapper;                              // implicit unboxing
        System.out.println("round trip      : " + back);

        // Integer.valueOf caches -128..127, so these are the same object.
        Integer cached = Integer.valueOf(127);
        Integer other  = Integer.valueOf(127);
        System.out.println("127 == 127      : " + (cached == other));

        // Outside the cache range each call allocates a new object.
        Integer big1 = Integer.valueOf(1000);
        Integer big2 = Integer.valueOf(1000);
        System.out.println("1000 == 1000    : " + (big1 == big2));
        System.out.println("1000 .equals    : " + big1.equals(big2));

        // Unboxing null throws NullPointerException.
        Integer maybe = null;
        try {
            int boom = maybe;
            System.out.println(boom);
        } catch (NullPointerException e) {
            System.out.println("unboxing null  : NullPointerException");
        }
    }
}

The practical takeaway for interviews: never compare wrappers with ==, and never let a wrapper field be null unless null is a meaningful value in your domain. When null is meaningful, keep the wrapper and check it explicitly rather than letting an implicit unboxing blow up somewhere else in the method.