What is the difference between a raw type, a parameterized type, and Box<Object>, and why does using a raw type defeat the purpose of generics?

## Three things people confuse For `class Box<T> { ... }` there are three distinct ways the name `Box` can appear, and conflating them is a classic source of bugs and warnings. ### 1. Parameterized type — `Box<String>` You supply a concrete **type argument**. The compiler enforces it everywhere: `set` only accepts `String`, `get` returns `String` with no cast. This is the normal, intended usage. ### 2. Raw type — `Box` You use the generic class with **no** angle brackets at all: ```java Box b = new Box(); // raw type b.set("hi"); b.set(42); // compiles! no type checking Object o = b.get(); // returns Object; you must cast to use it ``` A **raw type** is a generic type used without type arguments. It exists *only* for backward compatibility: code written before generics (Java 1.4 and earlier) used `Box` with no parameters, and that code still had to compile after generics were added in Java 5. Using a raw type **turns off generic type checking** for that reference. The compiler emits an **unchecked warning** because it can no longer guarantee type safety. ### 3. `Box<Object>` — a parameterized type, NOT raw This is the subtle one. `Box<Object>` is a *fully parameterized* type whose argument happens to be `Object`. Type checking is **still on**: ```java Box<Object> b = new Box<>(); b.set("hi"); // ok, String is an Object b.set(42); // ok, Integer is an Object (autoboxed) Object o = b.get(); // returns Object — but checking was never disabled ``` The difference from raw is visible in **assignment and signatures**: ```java void takesStringBox(Box<String> b) { ... } Box raw = new Box(); // raw Box<Object> objBox = new Box<>(); Box<String> strBox = new Box<>(); takesStringBox(raw); // compiles, with an UNCHECKED WARNING (unsafe) takesStringBox(objBox); // COMPILE ERROR: Box<Object> is not Box<String> takesStringBox(strBox); // ok ``` A raw `Box` is assignable (with a warning) to *any* `Box<...>`, which is exactly how it punches a hole in type safety. `Box<Object>` is a distinct parameterized type and the compiler keeps it strictly separate from `Box<String>` — generics are **invariant**, so `Box<Object>` is *not* a supertype of `Box<String>`. ## Why raw types defeat the purpose Generics exist to move type errors from **runtime** (`ClassCastException`) to **compile time**. A raw type opts out of that: ```java List raw = new ArrayList(); // raw List raw.add("hello"); raw.add(42); List<String> strings = raw; // unchecked warning String s = strings.get(1); // ClassCastException at RUNTIME — the bug generics were meant to catch ``` The whole investment in generics — compile-time safety, no casts — is thrown away the moment you use a raw reference, and the danger can propagate to other, properly-typed code through assignment. ## How the compiler treats raw types When you use a raw type, the compiler erases **all** the generics in that type's methods, not just the missing argument — so even methods that didn't mention `T` lose their generic signatures. This is why raw usage is more dangerous than it looks. ## Practical guidance - **Never** introduce raw types in new code. If you truly mean "any type," use a **wildcard** `Box<?>` (which keeps type safety: you can read as `Object` but cannot put non-null values in) rather than raw `Box`. - Reserve `Box<Object>` for when you genuinely want a box of arbitrary objects *and* you want to insert into it. - Treat unchecked warnings as errors in your build where possible. ## Why it matters Knowing the raw / `Box<?>` / `Box<Object>` distinction is the difference between safely interoperating with legacy code and silently reintroducing the runtime cast failures generics were designed to eliminate.