એ Java માટે (, ) અને તેમના (, ) વચ્ચેનું સ્વચાલિત રૂપાંતર છે. તે અનુકૂળ છે પરંતુ તેમાં સૂક્ષ્મ મુશ્કેલીઓ છે — કાર્યક્ષમતા ઓવરહેડ, આશ્ચર્યજનક વર્તન, અને જોખમ.
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
તે સ્વચાલિત રીતે થાય છે કારણ કે collections અને generics ને objects ની જરૂર છે (તમે List<int> રાખી શકતા નથી), તેથી Java primitives ને પારદર્શક રીતે બોક્સ કરે છે.
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
તે કપટી છે: Integer પર == નાના મૂલ્યો માટે કાર્ય કરે છે (ক્યાશ કરેલું) પરંતુ મોટા માટે નિષ્ફળ જાય છે — કોડ જે testing માં સાચો લાગે છે તે production માં તૂટી જાય છે. Wrapper મૂલ્ય સરખામણી માટે હંમેશા .equals() ઉપયોગ કરો, અથવા પહેલે primitives માટે unbox કરો.
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
Null wrapper ને unbox કરવો એ NPE ફેંકે છે — એક સામાન્ય, આશ્ચર્યજનક ક્રેશ, ખાસ કરીને map lookups સાથે જે 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
પુનરાવર્તિત boxing/unboxing અત્યધિક objects બનાવે છે, tight loops માં કાર્યક્ષમતાને નુકસાન પહોંચાડે છે.
Autoboxing અનુકૂળ અને સર્વવ્યાપી છે (collections, generics બધું તેના પર આધાર રાખે છે), પરંતુ તેની મુશ્કેલીઓ વાસ્તવિક, નિદાન કરવા માટે મુશ્કેલ bugs નું કારણ બને છે.
== trap ખાસ કરીને ખતરનાક છે: Integers ને == સાથે તુલના કરવી એ ક્યાશ કરેલા નાના મૂલ્યો (-128 થી 127) માટે કાર્ય કરે છે પરંતુ મોટા માટે શાંતથી નિષ્ફળ જાય છે — એક bug જે tests ને પાસ કરે છે અને production માં તૂટી જાય છે — wrapper સરખામણી માટે .equals() (અથવા unboxing) આવશ્યક બનાવે છે. NullPointerExceptions null wrappers (map lookups સાથે સામાન્ય) ને unbox કરવાથી અન્ય ધરતીપુષ્ઠ ક્રેશ છે.
અને boxing hot loops માં બિનજરૂરી objects બનાવે છે, કાર્યક્ષમતાને નુકસાન પહોંચાડે છે.
જ્યારે boxing થાય છે, મૂલ્ય-વિ-reference સરખામણી મુદ્દો, null-unboxing જોખમ, અને performance-critical code માં primitives ઉપયોગ કરવા સમજવો એ સાચો, કુશળ Java લખવા માટે મહત્વપૂર્ણ છે — અને Integer-cache == વર્તન એક ક્લાસિક interview પ્રશ્ન છે જે ઊંડી સમજણ દર્શાવે છે.