What Are Autoboxing and Unboxing in Java?

Autoboxing is the compiler converting a primitive value into its wrapper object; unboxing is the reverse. Neither conversion exists in the bytecode as an operator — the compiler desugars them into static factory calls and instance method calls, so Integer x = 5; becomes Integer x = Integer.valueOf(5); and int y = x; becomes int y = x.intValue();.

The compiler inserts these conversions in three places. Assignments and initialisations, as above. Method invocation, when the argument type and the parameter type differ only by boxing: passing an int to a method that takes an Integer boxes it, and passing an Integer to a method that takes an int unboxes it. And the compound-assignment operators, where x += 1 on a wrapper is compiled as x = x + 1 and therefore unboxes, boxes again and reassigns.

import java.util.ArrayList;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        int raw = 7;
        List<Integer> counts = new ArrayList<>();
        counts.add(raw);                 // autoboxing: int -> Integer
        int back = counts.get(0);        // unboxing: Integer -> int
        System.out.println("round trip        : " + back);

        Integer boxed = 42;              // autoboxing on assignment
        int unboxed = boxed;             // unboxing on assignment
        System.out.println("assignment        : " + unboxed);

        // Compound assignment unboxes, adds, then boxes again.
        Integer counter = Integer.valueOf(0);
        counter += 5;
        System.out.println("counter += 5      : " + counter);

        // Which overload gets picked also depends on boxing.
        System.out.println("overload          : " + describe(7));
        System.out.println("overload          : " + describe(Integer.valueOf(7)));
    }

    static String describe(int value)  { return "int overload"; }
    static String describe(Integer v)  { return "Integer overload"; }
}

The overload case is the sneaky one: because both int and Integer overloads exist, the compiler chooses the primitive version for an int argument and the wrapper version for an Integer argument, with no ambiguity error. That is why an API with both overloads behaves differently depending on whether the caller boxed the value.

Functionally there is no difference. The compiler emits exactly the same calls either way, so Integer x = 5; and Integer x = Integer.valueOf(5); produce identical bytecode, and int y = x; and int y = x.intValue(); likewise. The only difference is readability.

There is a case where being explicit pays off, and it is the one the JavaDoc flags as a deprecation: calling the new Integer(int) constructor. That constructor boxes unconditionally and allocates a fresh object every time, bypassing the cache that Integer.valueOf uses. It was deprecated long ago and has since been removed, so on any modern JDK it does not compile at all. Older interview material that teaches new Integer(5) is out of date, and a candidate who reaches for it today has not read the API since the deprecation.

Two behavioural differences remain between the explicit and implicit forms, and both are about the compiler's choices rather than about boxing itself. The first is overload resolution: as shown on this page, an int argument prefers an int overload and an Integer argument prefers an Integer overload, so switching between the explicit and implicit forms can change which method is called. The second is nullability: an unboxing conversion on a possibly-null wrapper throws NullPointerException at the point of use, so writing the conversion explicitly can move the failure earlier and make it easier to localise.

House style usually goes with the implicit form for ordinary code, and the explicit form where the intent needs to be obvious to a reader skimming the code.

Two separate mechanisms combine here. First, == on two Integer references compares object identity, not numeric value. Second, Integer.valueOf maintains a cache of boxed instances for the range -128 to 127 inclusive, and returns the same object for any value in that range. Values outside the range get a freshly allocated wrapper every time.

So for 127 both wrappers are the identical cached object and == returns true. For 128 the cache does not apply, so two separate Integer objects are created, the references differ, and == returns false even though the numbers are equal. The equals method compares numeric value and returns true in both cases.

The reason is that a lambda does not run immediately. The lambda body may execute long after the enclosing method has returned, possibly on another thread, and by then the enclosing frame is gone. If the lambda could see a variable that had been reassigned, it would have no way to know which value it was supposed to use, and the result would depend on timing.

Notice what the rule does not say. It does not require the captured object to be immutable. If you capture a StringBuilder and mutate it inside the lambda, that is perfectly legal, because the rule is about reassigning the variable, not about changing the object. The same applies to a field, which is not subject to the rule at all.

public class Main {
    public static void main(String[] args) {
        Integer a = 127;
        Integer b = 127;
        Integer c = 128;
        Integer d = 128;

        System.out.println("127 == 127  (references): " + (a == b));
        System.out.println("128 == 128  (references): " + (c == d));
        System.out.println("128 equals 128          : " + c.equals(d));
        System.out.println("default cache range     : -128..127");

        // The cache is per-JVM and can be widened with -XX:AutoBoxCacheMax.
        System.out.println("same instance at 1000   : "
            + (Integer.valueOf(1000) == Integer.valueOf(1000)));

        // Unboxing before comparing gives the numeric answer every time.
        System.out.println("unboxed compare         : " + (c.intValue() == d.intValue()));
    }
}

The bug this causes in production code is real: a map key or a cache lookup that compares boxed keys with == works for small values and silently fails for large ones, which is the classic symptom of an identity bug that passes testing on small data and breaks in production. The fix is always to use equals for value comparison, or to unbox explicitly with intValue() before comparing. Two related points worth adding: the cache size can be tuned with the -XX:AutoBoxCacheMax JVM flag, which changes exactly where the boundary sits, and autoboxing in a hot loop allocates a wrapper per iteration for any value outside the cache, which is a genuine source of garbage-collection pressure in large numeric workloads.