In Java, why do we need wrapper classes such as Integer, Double, and Boolean when primitive types like int, double, and boolean already exist?

Introduction / Context:
This question explores the reason Java provides wrapper classes for primitive types. Primitive types like int and double are efficient and simple, but they are not objects and therefore cannot be used everywhere an Object is required. Wrapper classes bridge this gap by providing an object representation of primitive values, enabling integration with the rest of the object oriented features of the language and standard library.

Given Data / Assumptions:

- Java has eight primitive types and corresponding wrapper classes such as Integer, Double, and Boolean.
- Many Java APIs, including collections and generics, work only with reference types, not primitive types.
- Wrapper classes also provide utility methods that primitives do not have, such as parsing from strings and converting to strings in specific formats.

Concept / Approach:
Primitives are stored directly as simple values and are not objects. They cannot be used as type parameters in generics, cannot be stored directly in collections like ArrayList, and do not have methods. Wrapper classes are regular Java classes that encapsulate primitive values in objects. For example, an Integer object wraps an int value. This allows primitive values to participate in object oriented constructs, such as being elements in collections, keys in maps, and generic type arguments. Wrapper classes also provide static methods like Integer.parseInt and instance methods such as intValue, which support parsing and conversion operations.

Step-by-Step Solution:
Step 1: Consider a collection such as List<Integer>. Because generics require reference types, you cannot declare List<int> in Java. Instead you must use the Integer wrapper class for int values. Step 2: When using methods such as Collections.max or Collections.sort, you benefit from the Comparable or Comparator interfaces, which rely on object based comparisons that wrapper classes can implement. Step 3: Note that wrapper classes provide parsing utilities such as Integer.parseInt("42"), Double.parseDouble("3.14"), and Boolean.parseBoolean("true") that convert strings to primitive values. Step 4: Thanks to autoboxing and unboxing, Java automatically converts between primitives and their wrapper types in many contexts, but the underlying reason for wrapper classes remains the need for object representations. Step 5: Option A correctly captures the main motivations: storing primitives in collections, using generics, and accessing utility methods.

Verification / Alternative check:
If you try to compile code that declares a generic type parameter with a primitive, such as List<int>, the compiler will reject it. Only wrapper types are allowed. At the same time, you can create arrays of primitives directly, such as int[] nums, which demonstrates that primitives are supported by the language but not usable everywhere an Object is needed. This behavior confirms that wrapper classes fill the gap, as described in option A.

Why Other Options Are Wrong:
Option B is wrong because primitive types are very much supported by Java and are used heavily in practice. Option C incorrectly claims that wrapper classes always improve performance; in fact, wrappers add overhead due to object allocation and indirection, so primitives are usually faster in tight loops. Option D is incorrect because primitives can certainly be used in arrays; wrapper classes are not required for that purpose.

Common Pitfalls:
A common pitfall is overusing wrapper classes when primitives would be more efficient, especially inside large numeric loops. Another issue is forgetting that wrapper classes can be null, which may cause NullPointerException when auto unboxing occurs. Developers should balance the need for object behavior with performance considerations and be aware of when conversions between primitives and wrappers occur.

Final Answer:
Java provides wrapper classes so that primitive values can be treated as full objects, letting them be used with generics, stored in collections, and processed with useful parsing and conversion methods that primitives alone do not provide.