je automatická konverze Java mezi (, ) a jejich (, ). Je pohodlné, ale má jemná úskalí — výkonnostní režie, překvapivé chování a riziko .
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
Dochází k tomu automaticky, protože kolekce a generika vyžadují objekty (nemůžete mít List<int>), takže Java transparentně boksuje primitvy.
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
Toto je lstivé: == na Integer funguje pro malé hodnoty (cachovány), ale selhává pro velké — kód, který se zdá správný v testech, se v produkci rozpadá. Vždy používejte .equals() pro porovnání hodnot obálky nebo nejdřív unboxujte na primitvy.
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 null obálky vyvolá NPE — běžný, překvapivý pád, zvláště s vyhledáváním v mapách, která vrací 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
Opakované boxování/unboxování vytváří nadměrné objekty, což poškozuje výkon v těsných smyčkách.
Autoboxing je pohodlné a všudypřítomné (kolekce, generika na něm závisí), ale jeho úskalí způsobují reálné, těžko diagnostikovatelné chyby.
Léčka == je obzvláště nebezpečná: porovnání Integer s == funguje pro cachovované malé hodnoty (-128 až 127), ale tiše selhává pro větší — chyba, která projde testy a v produkci se zhroutí — činí .equals() (nebo unboxing) nezbytný pro porovnání obálky. NullPointerExceptions z unboxingu null obálek (běžné s vyhledáváním v mapách) je další časté selhání.
A boxování v hot loops vytváří zbytečné objekty, což poškozuje výkon.
Rozmíšení, kdy k boxování dochází, problém porovnání hodnoty versus reference, riziko null-unboxingu a používání primitvů v kritickém kódu je důležité pro psaní správné a efektivní Javy — a chování == cache Integer je klasická otázka v pohovorech, která odhaluje hluboké pochopení.