Wrapper Classes

In short: Classes that “wrap” a primitive data type as an object — e.g. Integer for int, Double for double, Boolean for boolean.

In more detail: Collections like List can only store objects, not primitive types directly — List<int> is therefore invalid, List<Integer>, by contrast, works. The automatic conversion between primitive type and wrapper (autoboxing/unboxing) is usually handled invisibly by the compiler, but can cost performance for very many conversions.

In Depth

int primitive = 5;
Integer object = primitive;      // autoboxing: automatically wrapped into Integer
int back = object;           // unboxing: automatically unwrapped again
 
List<Integer> numbers = new ArrayList<>();
numbers.add(10); // int is automatically boxed into Integer
 
Integer a = 100;
Integer b = 100;
System.out.println(a == b);     // true - small values (-128 to 127) are cached
 
Integer c = 200;
Integer d = 200;
System.out.println(c == d);     // false! - outside the cache, two genuine objects
System.out.println(c.equals(d)); // true - content compared correctly

Every primitive type has exactly one matching wrapper class: int → Integer, double → Double, boolean → Boolean, char → Character, etc. Since Java 5, the compiler usually handles the conversion between both worlds invisibly (autoboxing when wrapping, unboxing when unwrapping) — convenient, but not free: every boxing operation can create a new object on the heap, which can be noticeably slower in performance-critical loops with very many conversions than pure primitive arithmetic.

A well-known pitfall: Java internally caches small Integer values between -128 and 127, so == returns true by coincidence for these values (as in the a == b example above), but outside this range two separate objects are created and == returns false. Just as with String, the rule therefore is: always use .equals() instead of == for a reliable value comparison of wrapper objects. A second risk: Integer (object) can be null, int (primitive) never can — automatic unboxing of null throws a NullPointerException.

See also: Non-primitive Types, Generics, Collections