is de automatische conversie in Java tussen (, ) en hun (, ). Het is handig maar heeft subtiele valkuilen — prestatieoverhead, verrassend gedrag en risico.
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
Het gebeurt automatisch omdat collecties en generics objecten vereisen (je kan geen List<int> hebben), dus Java verpakt primitieven transparant.
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
Dit is verraderlijk: == op Integer werkt voor kleine waarden (gecacht) maar faalt voor grote waarden — code die correct lijkt in testen breekt in productie. Gebruik altijd .equals() voor wrapperwaardevergelijking, of unbox naar primitieven eerst.
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
Unboxing van een null wrapper veroorzaakt een NPE — een veelvoorkomende, verrassende crash, vooral bij mapzoekingen die null retourneren.
// ❌ 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
Herhaald boxing/unboxing creëert excessieve objecten, wat de prestaties in strakke lussen schaadt.
Autoboxing is handig en alomtegenwoordig (collecties, generics vertrouwen er allemaal op), maar de valkuilen veroorzaken echte, moeilijk na te sporen bugs.
De == valkuil is vooral gevaarlijk: het vergelijken van Integers met == werkt voor gecachte kleine waarden (-128 tot 127) maar faalt stilzwijgend voor grotere — een bug die testen doorstaat en in productie breekt — waardoor .equals() (of unboxing) essentieel is voor wrappervergelijking. NullPointerExceptions van unboxing van null wrappers (algemeen bij mapzoekingen) zijn nog een veelvoorkomende crash.
En boxing in hete lussen creëert onnodige objecten, wat de prestaties schaadt.
Begrip wanneer boxing gebeurt, het waarde-versus-referentievergelijkingsprobleem, het null-unboxing risico en het gebruik van primitieven in prestatie-kritieke code is belangrijk voor het schrijven van correcte, efficiënte Java — en het Integer-cache == gedrag is een klassieke interviewvraag die diep begrip onthult.