es la conversión automática de Java entre (, ) y sus (, ). Es conveniente pero tiene inconvenientes sutiles — sobrecarga de rendimiento, comportamiento sorprendente de y riesgo de .
intdoubleIntegerDouble==NullPointerExceptionInteger boxed = 42; // autoboxing: int → Integer (Integer.valueOf(42))
int unboxed = boxed; // auto-unboxing: Integer → int (boxed.intValue())
List<Integer> nums = new ArrayList<>();
nums.add(5); // autoboxes int 5 → Integer (collections need objects)
int x = nums.get(0); // auto-unboxes Integer → int
Ocurre automáticamente porque las colecciones y genéricos requieren objetos (no puedes tener List<int>), así que Java encapsula primitivos de forma transparente.
Integer a = 1000;
Integer b = 1000;
a == b; // ❌ FALSE — different Integer OBJECTS (reference comparison)
a.equals(b); // ✅ true — value comparison
// the WORSE trap — the Integer cache makes small values seem to work:
Integer c = 100, d = 100;
c == d; // TRUE — Java CACHES Integers from -128 to 127 (same object)
Integer e = 200, f = 200;
e == f; // FALSE — outside the cache range → different objects
Esto es insidioso: == en Integer funciona para valores pequeños (en caché), pero falla para valores grandes — código que parece correcto en pruebas se rompe en producción. Siempre usa .equals() para comparación de valores de envoltorios, o desencapsula a primitivos primero.
Integer value = null; // a wrapper can be null
int x = value; // 💥 NullPointerException — unboxing null calls null.intValue()
Map<String, Integer> map = new HashMap<>();
int count = map.get("missing"); // 💥 NPE — get() returns null, then unboxing fails
Desencapsular un envoltorio null lanza una NPE — un bloqueo común y sorprendente, especialmente con búsquedas de mapa que devuelven null.
// ❌ autoboxing in a hot loop — creates millions of Integer objects (GC pressure, slow)
Long sum = 0L; // WRONG type — wrapper
for (long i = 0; i < 1_000_000; i++) {
sum += i; // unbox, add, re-box → new Long each iteration!
}
// ✅ use primitives in hot paths
long sum = 0L; // primitive — no boxing
El encapsulamiento/desencapsulamiento repetido crea objetos excesivos, lo que daña el rendimiento en bucles ajustados.
Autoboxing es conveniente y ubicuo (las colecciones, genéricos dependen de él), pero sus inconvenientes causan errores reales y difíciles de diagnosticar.
La trampa == es especialmente peligrosa: comparar Integer con == funciona para valores pequeños en caché (-128 a 127), pero falla silenciosamente para valores más grandes — un error que pasa pruebas y se rompe en producción — haciendo .equals() (o desencapsulamiento) esencial para comparación de envoltorios. NullPointerExceptions del desencapsulamiento de envoltorios null (comunes con búsquedas de mapa) son otro bloqueo frecuente.
Y el encapsulamiento en bucles calientes crea objetos innecesarios, dañando el rendimiento.
Comprender cuándo ocurre el encapsulamiento, el problema de comparación de valor versus referencia, el riesgo de desencapsulamiento null y el uso de primitivos en código crítico para el rendimiento es importante para escribir Java correcta y eficiente — y el comportamiento == de la caché de Integer es una pregunta clásica de entrevista que revela una comprensión profunda.