என்பது (, ) மற்றும் அவற்றின் (, )-க்கு இடையே Java-வின் தானியங்கி மாற்றம் ஆகும். இது வசதியானது ஆனால் நுட்பமான ஆபத்துகள் உள்ளன — செயல்திறன் overhead, ஆச்சரியமான behavior, மற்றும் ஆபத்து.
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-ஐ வெளிப்படையாக box செய்கிறது.
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-இல் == சிறிய values-க்கு (cached) வேலை செய்கிறது ஆனால் பெரியவற்றுக்கு தோல்வியடைகிறது — testing-இல் சரியாகத் தோன்றும் code production-இல் உடைகிறது. wrapper value comparison-க்கு எப்போதும் .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-ஐ எறிகிறது — ஒரு பொதுவான, ஆச்சரியமான crash, குறிப்பாக null-ஐ திருப்பித் தரும் map lookups-உடன்.
// ❌ 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-ஐ உருவாக்குகிறது, இறுக்கமான loops-இல் செயல்திறனை பாதிக்கிறது.
Autoboxing வசதியானது மற்றும் பரவலானது (collections, generics அனைத்தும் அதை நம்பியுள்ளன), ஆனால் அதன் ஆபத்துகள் உண்மையான, கண்டறிய-கடினமான bugs-ஐ ஏற்படுத்துகின்றன.
== பொறி குறிப்பாக ஆபத்தானது: Integer-களை == உடன் ஒப்பிடுவது cached சிறிய values-க்கு (-128 முதல் 127) வேலை செய்கிறது ஆனால் பெரியவற்றுக்கு அமைதியாக தோல்வியடைகிறது — tests-ஐ கடந்து production-இல் உடையும் ஒரு bug — wrapper comparison-க்கு .equals() (அல்லது unboxing)-ஐ அவசியமாக்குகிறது. null wrappers-ஐ unbox செய்வதிலிருந்து NullPointerExceptions (map lookups-உடன் பொதுவானது) மற்றொரு அடிக்கடி நிகழும் crash ஆகும்.
மேலும் hot loops-இல் boxing தேவையற்ற objects-ஐ உருவாக்குகிறது, செயல்திறனை பாதிக்கிறது.
boxing எப்போது நிகழ்கிறது, value-vs-reference comparison சிக்கல், null-unboxing ஆபத்து, மற்றும் செயல்திறன்-முக்கியமான code-இல் primitives-ஐ பயன்படுத்துவது ஆகியவற்றைப் புரிந்துகொள்வது சரியான, திறமையான Java எழுதுவதற்கு முக்கியம் — மேலும் Integer-cache == behavior ஆழமான புரிதலை வெளிப்படுத்தும் ஒரு கிளாசிக் interview கேள்வி ஆகும்.