Primitives, wrappers, and the == trap

Java has eight primitive types — int, long, double, float, boolean, char, byte, short — and each has a corresponding wrapper class: Integer, Long, Double, and so on. A primitive is a raw value; a wrapper is a real object, which is the only kind of thing a generic collection can hold.

int a = 5;              // a primitive value
Integer b = 5;           // an Integer object — this is autoboxing
List<Integer> nums = new ArrayList<>();
nums.add(5);              // autoboxed to Integer on the way in
int first = nums.get(0);  // auto-unboxed back to int on the way out

List<int> does not compile — generics only work with reference types, which is the entire reason autoboxing exists: it lets 5 be written where an Integer is needed, and the compiler inserts the conversion.

Try it

The == trap

== on two primitives compares values. == on two objects — which includes wrapper types — compares references: are these the exact same object in memory.

Integer a = 127;
Integer b = 127;
a == b;          // true

Integer c = 200;
Integer d = 200;
c == d;          // false

Both pairs look identical. The difference is that boxing reuses cached Integer objects for -128 to 127 — the language specification requires that range, and a JVM flag can raise the upper end, so anything outside it may or may not be a fresh object. 127 == 127 is comparing two references to the same cached object; 200 == 200 is comparing two separately allocated objects that happen to hold the same value. The cache range is exactly wide enough to make a bug look like it works in a quick test and fail once real numbers show up.

The fix is the same one every language with this trap needs: compare wrapper objects with .equals(), not ==.

Integer c = 200;
Integer d = 200;
c.equals(d);   // true — always, regardless of caching

Unboxed primitives never have this problem — int c = 200; int d = 200; c == d is true unconditionally, because there is no object identity to compare, only the value.

Common mistakes

• Comparing two Integers with ==. It passes every test that uses small numbers and fails in production with an order id of 1000.

What interviewers ask

• Why can't you declare a List<int>? Type arguments must be reference types; generics are erased to Object at runtime, and a primitive is not an Object.
• Integer a = 127, b = 127; a == b is true, but with 128 it is false. Why? == compares references; boxing goes through Integer.valueOf, which returns cached objects for -128 to 127 and may allocate new ones outside that range. Compare with equals.
• What does autoboxing cost? A possible allocation per boxed value, an extra indirection on every read, and a NullPointerException on unboxing null. In a hot loop over millions of numbers, a primitive array or IntStream avoids all three.