Challenge 3: Why List<int> Doesn't Compile — Possible Solution ==================================================================== java1-2's own material established that Java has exactly eight primitive types (byte, short, int, long, float, double, char, boolean) as a genuinely distinct category from reference types -- primitives are stored directly (on the stack or inline), never as an object, and never as something a reference can point to. Java's generics work by substituting a REFERENCE type into the type parameter at compile time -- a generic class like List is fundamentally built around T being something that behaves like an object (something a reference can point to, something that has methods, something nullable). A raw primitive like int satisfies none of that: it isn't a reference, has no methods of its own, and can never be null. List has nothing valid to substitute in for T, so it's rejected at compile time. List compiles because Integer -- the wrapper class from java1-2 -- IS a genuine reference type, and autoboxing supplies the bridge whenever a raw int needs to become one. C++'s std::vector faces no such restriction, because C++ templates work completely differently: the compiler generates an entirely separate, specialized version of vector for int specifically, storing real int values directly in contiguous memory -- no wrapper object, no boxing, no reference indirection at all. Java's generics are erased to a single shared implementation at compile time (type erasure, covered in full in java2-1), which is exactly why they can only work with reference types in the first place. WHY THIS WORKS AS AN ANSWER ------------------------------ This connects List's compile failure directly back to java1-2's own primitive-vs-reference distinction (generics require a reference type to substitute in), and correctly contrasts it with C++ templates' different strategy (real per-type code generation, no boxing needed), matching the chapter's own stated comparison to std::vector.