Autoboxing کیا ہے اور اس کے نقصانات کیا ہیں؟

Question

Accepted Answer

**Autoboxing** Java کی **primitives** (`int`, `double`) اور ان کے **wrapper objects** (`Integer`, `Double`) کے درمیان خودکار تبدیلی ہے۔ یہ سہل ہے لیکن اس میں لطیف نقصانات ہیں — کارکردگی کا اضافی بوجھ، حیران کن `==` رویہ، اور `NullPointerException` کا خطرہ۔ ## Autoboxing اور unboxing ```java Integer boxed = 42; // autoboxing: int → Integer (Integer.valueOf(42)) int unboxed = boxed; // auto-unboxing: Integer → int (boxed.intValue()) List 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` نہیں ہو سکتا)، اس لیے Java primitives کو شفاف طریقے سے box کرتا ہے۔ ## نقصان 1: == wrappers کے لیے references کا موازنہ کرتا ہے، قدریں نہیں ```java 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` پر `==` چھوٹی قدریوں کے لیے کام کرتا ہے (cached) لیکن **بڑی قدریوں کے لیے ناکام ہوتا ہے** — وہ کوڈ جو ٹیسٹنگ میں صحیح لگتا ہے production میں ٹوٹ جاتا ہے۔ wrapper کی قدر کے موازنے کے لیے ہمیشہ `.equals()` استعمال کریں، یا پہلے primitives کو unbox کریں۔ ## نقصان 2: unboxing پر NullPointerException ```java Integer value = null; // a wrapper can be null int x = value; // 💥 NullPointerException — unboxing null calls null.intValue() Map map = new HashMap<>(); int count = map.get("missing"); // 💥 NPE — get() returns null, then unboxing fails ``` کسی `null` wrapper کو unbox کرنا NPE پھینکتا ہے — ایک عام، حیران کن خرابی، خاص طور پر map lookups کے ساتھ جو null واپس کرتے ہیں۔ ## نقصان 3: کارکردگی کا اضافی بوجھ ```java // ❌ 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 کا سبب بنتے ہیں۔ **`==` کا پھندا** خاص طور پر خطرناک ہے: `Integer` کا `==` سے موازنہ cached چھوٹی قدریوں (-128 سے 127) کے لیے کام کرتا ہے لیکن بڑی قدریوں کے لیے خاموشی سے ناکام ہوتا ہے — ایک bug جو ٹیسٹ میں پاس ہوتا ہے اور production میں ٹوٹتا ہے — wrapper موازنے کے لیے `.equals()` (یا unboxing) ضروری بناتا ہے۔ **NullPointerExceptions** null wrappers کو unbox کرنے سے (عام طور پر map lookups کے ساتھ) ایک اور عام خرابی ہے۔ اور **hot loops** میں boxing سے غیر ضروری objects بنتے ہیں، جو کارکردگی کو نقصان پہنچاتا ہے۔ یہ سمجھنا کہ boxing کب ہوتی ہے، value-vs-reference موازنے کا مسئلہ، null-unboxing کا خطرہ، اور کارکردگی سے متعلقہ کوڈ میں primitives استعمال کرنا صحیح، موثر Java لکھنے کے لیے اہم ہے — اور Integer-cache `==` رویہ ایک کلاسیک انٹرویو سوال ہے جو گہری سمجھ کا مظہر ہے۔