is Java's automatic conversion between (, ) and their (, ). It's convenient but has subtle pitfalls — performance overhead, surprising behavior, and risk.
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
Tarlaíonn sé go huathoibríoch toisc go dteastaíonn rudaí ó bhailiúcháin agus ginearálachas (ní féidir List<int> a bheith agat), agus dá bhrí sin déanann Java primitives a bhoscaradh go soiléir.
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
Tá sé seo dochreachta: oibríonn == ar Integer do luachanna beaga (cachéd) ach theipeann sé ar chinn mhóra — briseann cód a bhraistear a bheith ceart i dtástáil i dtáirgeoireacht. Úsáid .equals() i gcónaí chun comparáid luach wrappers a dhéanamh, nó unbox go primitives ar dtús.
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
Tuairimíonn unboxing a null wrapper NPE — tuairisctheoirí coitianta agus iontas, go háirithe le cuardach léarscáil a fhilleann 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
Cruthóionn boscaradh/unboxing arís agus arís eile rudaí iomarcach, ag gealadh feidhmíochta i lúpanna teann.
Tá autoboxing áisiúil agus i bhfoluain (bailiúcháin, ginearálachas ar fad ag fíorú air), ach is cúis iad na gealltanais aige d'fhíorbhuaicí deacra-diagnóistiochta.
Tá an == trap go háirithe contúirteach: oibríonn comparáid Integereans le == do luachanna beaga cachéd (-128 go 127) ach theipeann sé go ciúin ar chinn níos mó — fabht a théann tríd thástáil agus a bhríseann i dtáirgeoireacht — agus dá bhrí sin tá .equals() (nó unboxing) fíorthábhachtach le haghaidh comparáid wrappers. NullPointerExceptions ó unboxing null wrappers (coitianta le cuardach léarscáil) is cúis eile shonraithí d'thubaiste.
Agus boscaradh i loops te cruthóionn sé rudaí neamhghá, ag gealadh feidhmíochta.
Tá sé tábhachtach a thuiscint cathain a bhíonn boscaradh ag tarlú, an cheist comparáid luach-vs-tagartha, an risc null-unboxing, agus primitives a úsáid i gcód tábhachtach feidhmíochta chun Java ceart agus éifeachtach a scríobh — agus is ceist agallamh clasaiceach é an t-iompar == Integer-cache go léiríonn sé tuiscint dhomhain.
Leabharlann de cheisteanna agallaimh TF le freagraí mionsonraithe — ó Shóisearach go Sinsearach.
Síntiús