je automatska konverzija Jave između (, ) i njihovih (, ). Zgodno je, ali ima suptilne nedostatke — overhead performansi, neočekivano ponašanje operatora i rizik od .
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
Dešava se automatski jer kolekcije i generici zahtijevaju objekte (ne možete imati List<int>), pa Java prozirno pakuje primitivne tipove.
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
Ovo je neugodno: == na Integer funkcionira za male vrijednosti (cache-irane), ali ne uspijeva za velike — kod koji izgleda ispravan tijekom testiranja prekida se u produkciji. Uvijek koristite .equals() za usporedbu vrijednosti wrapper-a ili prvo raspakujte u primitivne tipove.
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
Raspakivanje null wrapper-a baca NPE — čest, iznenadujući pad, posebno kod map pretraga koje vraćaju 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
Ponovljeno pakovanje/raspakovanje stvara pretjerane objekte, što šteti performansama u uskim petljama.
Autoboxing je zgodno i sveprisutan (kolekcije, generici sve se oslanjaju na njega), ali njegovi nedostaci uzrokuju prave, teško dijagnosticirane greške.
Zamka == je posebno opasna: usporedba Integer-a s == funkcionira za cache-irane male vrijednosti (-128 do 127), ali tiho ne uspijeva za veće — greška koja prolazi testove i prekida se u produkciji — čineći .equals() (ili raspakovanje) nužnim za usporedbu wrapper-a. NullPointerException-i iz raspakovanja null wrapper-a (česti kod map pretraga) su još jedan česti pad.
I pakovanje u vrućim petljama stvara nepotrebne objekte, što šteti performansama.
Razumijevanje kad se pakovanje događa, problem usporedbe vrijednosti-vs-reference, rizik od raspakovanja null-a i korištenje primitivnih tipova u kodu kritičnom za performanse važno je za pisanje ispravnog, učinkovitog Jave — a ponašanje Integer-cache-a == je klasično pitanje na razgovoru za posao koje otkriva duboko razumijevanje.