Primitives & Wrappers

A wrapper class such as Integer, Double, or Boolean boxes a primitive into a real object, so it can be stored in generics and collections, which hold objects only. Autoboxing converts a primitive to its wrapper automatically (e.g. int to Integer), and unboxing converts the wrapper back to a primitive, so you can mix the two without explicit conversions.

An array is a language construct of fixed length, exposed through a length field. It can store primitives directly, and it is covariant, so a wrong store is caught only at run time as an ArrayStoreException. An ArrayList is a library class that wraps an array and grows on demand; it exposes size() and add(), stores objects only, so primitives are boxed, and it is generic and invariant, so a wrong element type is rejected at compile time.

r1 is true, r2 is false, r3 is false. Autoboxing calls Integer.valueOf, which caches instances for -128..127, so 100 returns the same cached object (== true), but 200 is outside the range and boxes a fresh object each time (== false). new Integer(100) always allocates, so two new calls are never ==.

Three classic ones. == between two Integer values compares references, so it is true for 127 from the -128..127 cache yet false for 128 — an equality that passes small tests and fails in production. Unboxing a null wrapper throws a NullPointerException on a line with no visible dereference, such as int x = map.get(missing). And boxing shifts overload resolution: list.remove(1) on a List<Integer> removes by index, list.remove(Integer.valueOf(1)) by value.

Because it has primitive types like int, char, and boolean that are not objects: they have no methods, do not descend from Object, and live as plain values rather than on the heap. A pure OO language would treat everything as an object. Java keeps primitives for performance and bridges them into the object world with wrapper classes like Integer.