Generics & type safety.

The pre-2004 pain — why generics exist

Before Java 5, collections held Object — the universal supertype. So you could put anything in:

List list = new ArrayList();
list.add("hello");
list.add(42); // totally legal
list.add(new User()); // also legal!

String s = (String) list.get(1); // 💥 ClassCastException at runtime

Three problems:

1. You couldn't tell from a method signature what kind of objects a list held
2. You had to cast on every retrieval
3. Type errors crashed at runtime, not at compile time

What <T> actually does

The angle brackets declare a type parameter — a placeholder that gets filled in when the class is used.

// A generic class — T is a placeholder
public class Box<T> {
  private T content;
  public void set(T value) { this.content = value; }
  public T get() { return content; }
}

// Usage — fill in the T
Box<String> stringBox = new Box<>();
stringBox.set("hi");
String s = stringBox.get(); // no cast needed

stringBox.set(42); // 💥 won't compile — wrong type

The compiler enforces: this Box can only hold Strings. Try to put an int → compiler error before your code even runs.

The trick — type erasure

Here's the part that surprises everyone: generics exist only at compile time. After compilation, the type parameters are erased. The bytecode treats Box<String> the same as Box<Integer> — both are just Box.

List<String> names = new ArrayList<>();
names.add("alice");
String name = names.get(0);

List names = new ArrayList();
names.add("alice");
String name = (String) names.get(0); // cast injected

Why care? Because erasure has consequences:

Consequence 1 · You can't do this

if (obj instanceof List<String>) { ... } // 💥 won't compile

At runtime, there's no type info. You can only check raw List.

Consequence 2 · You can't create generic arrays

T[] arr = new T[10]; // 💥 won't compile

Workaround: use List<T> instead, or Array.newInstance() with a class token.

Consequence 3 · You can't have static fields of type T

class Box<T> {
  static T cache; // 💥 won't compile
}

Static is one-per-class. T is per-instance. Conceptually they fight.

Wildcards — ?, extends, super

This is where most learners give up. Don't. There are only three patterns and one mnemonic.

The unbounded wildcard <?>

"A list of some type, I don't know which." You can read from it (as Object) but can't add to it.

void printAll(List<?> items) {
  for (Object o : items) System.out.println(o);
  // items.add(...) — won't compile, type unknown
}

Upper bounded · <? extends T> · "PRODUCER"

"Some subtype of T (or T itself)." You can read safely as T. You cannot add (you don't know the exact subtype).

double sum(List<? extends Number> numbers) {
  double total = 0;
  for (Number n : numbers) total += n.doubleValue();
  return total;
}

// All of these now work:
sum(List.of(1, 2, 3));            // List<Integer>
sum(List.of(1.0, 2.5));           // List<Double>

Lower bounded · <? super T> · "CONSUMER"

"Some supertype of T (or T itself)." You can add Ts to it safely. You cannot read as T (only as Object).

void addNumbers(List<? super Integer> bag) {
  bag.add(1);
  bag.add(42); // safe — Integer fits anywhere accepting Integer or higher
}

// All of these work:
addNumbers(new ArrayList<Integer>());
addNumbers(new ArrayList<Number>());
addNumbers(new ArrayList<Object>());

Bounded type parameters

Sometimes you want to require T to have certain capabilities. Use <T extends ...>:

// T must implement Comparable so we can call .compareTo()
public <T extends Comparable<T>> T max(List<T> list) {
  T best = list.get(0);
  for (T item : list) {
    if (item.compareTo(best) > 0) best = item;
  }
  return best;
}

How Spring uses generics — recognize this

You'll see these patterns constantly:

// Spring Data JPA — define your repo interface
public interface UserRepository extends JpaRepository<User, Long> {
  Optional<User> findByEmail(String email);
}

// JpaRepository<T, ID> — T is your entity, ID is its primary-key type
// Spring generates the implementation at runtime using these types

// ResponseEntity — generic over the response body type
ResponseEntity<UserDto> response = ResponseEntity.ok(userDto);

// Optional — wraps "value or absence"
Optional<User> maybe = userRepo.findById(id);

Generic methods — the angle brackets in front

You can declare type parameters on a single method, even in a non-generic class:

public <T> List<T> repeat(T item, int n) {
  List<T> out = new ArrayList<>();
  for (int i = 0; i < n; i++) out.add(item);
  return out;
}

// Usage — T is inferred
List<String> hellos = repeat("hi", 3);
List<Integer> zeros = repeat(0, 5);

Common generic mistakes

• Using raw types in new code. List list = ... instead of List<String>. The compiler warns; ignore at your peril.
• Excessive wildcards. If your method takes List<? extends Object>, that's just List<?>. Don't be fancy.
• Trying to use T at runtime. Erasure bites — pass Class<T> as a parameter when you need it.
• Confusing extends in generics with extends in inheritance. They use the same keyword but mean different things.

End of Day 5. Tomorrow: Java 8 reading fluency — Streams, Lambdas, Optional. The features you'll see in every modern Spring codebase.