Integer, Double, Autoboxing and Unboxing

An ArrayList stores objects, full stop. A plain int is a primitive, not an object, so ArrayList<Integer> cannot hold raw ints directly. Java bridges this gap automatically: when you write list.add(5), the compiler quietly converts that 5 into an Integer object before storing it. That conversion is autoboxing. Unboxing runs the other way: when you pull an Integer out of a list and use it in arithmetic, Java automatically extracts the plain int value so the math works. You never write the conversion code yourself; the compiler inserts it.

This convenience hides a real object underneath. Integer objects behave like any other object when compared with ==, which checks whether two variable names point to the same memory location, not whether they hold equal values. Java caches small boxed values from -128 to 127 for efficiency, so two Integers in that range often do point to the same cached object and == can accidentally return true. Outside that range, each boxing creates a fresh object, and == correctly returns false even when the values match, since .equals() is the method meant for comparing value equality.

Unboxing also fails loudly when there is nothing to unbox. A null Integer has no int value hiding inside it, so any arithmetic or comparison that forces unboxing throws a NullPointerException. This matters constantly in Unit 4, where ArrayLists of Integer get searched, sorted, and summed, autoboxing and unboxing on nearly every line without announcing itself.