adalah konversi otomatis Java antara (, ) dan mereka (, ). Ini nyaman tetapi memiliki pitfall yang subtle — overhead performa, perilaku yang mengejutkan, dan risiko .
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
Ini terjadi secara otomatis karena collections dan generics memerlukan objects (Anda tidak dapat memiliki List<int>), jadi Java membungkus primitives secara transparan.
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
Ini sangat berbahaya: == pada Integer bekerja untuk nilai kecil (cached) tetapi gagal untuk nilai besar — kode yang terlihat benar saat testing rusak di production. Selalu gunakan .equals() untuk perbandingan nilai wrapper, atau unbox ke primitives terlebih dahulu.
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 wrapper null melemparkan NPE — crash yang umum dan mengejutkan, terutama dengan map lookups yang mengembalikan 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 berulang menciptakan objects berlebihan, merusak performa dalam tight loops.
Autoboxing nyaman dan tersebar luas (collections, generics semuanya bergantung padanya), tetapi pitfallnya menyebabkan bug nyata yang sulit didiagnosis.
Trap == sangat berbahaya: membandingkan Integer dengan == bekerja untuk nilai kecil yang cached (-128 hingga 127) tetapi secara diam-diam gagal untuk nilai yang lebih besar — bug yang lolos dari tests dan rusak di production — membuat .equals() (atau unboxing) esensial untuk perbandingan wrapper. NullPointerExceptions dari unboxing wrapper null (umum dengan map lookups) adalah crash frequent lainnya.
Dan boxing dalam hot loops menciptakan objects yang tidak perlu, merusak performa.
Memahami kapan boxing terjadi, isu value-vs-reference comparison, risiko null-unboxing, dan menggunakan primitives dalam kode performance-critical penting untuk menulis Java yang benar dan efisien — dan perilaku Integer-cache == adalah pertanyaan interview klasik yang mengungkap pemahaman yang mendalam.