Generics

// Pre-generics (raw type): no compile-time type safety
List list = new ArrayList();
list.add("hello");
list.add(42);  // compiles fine, but mixes types!
String s = (String) list.get(1);  // throws ClassCastException at RUNTIME

// With generics: compile-time type safety
List<String> typedList = new ArrayList<>();
typedList.add("hello");
// typedList.add(42);  // COMPILE ERROR, caught immediately

Common follow-ups: Why does the compiler still allow raw types at all, given generics have been available since Java 5?;What specific runtime behavior differs between a raw type and its generic equivalent despite type erasure?

List<String> stringList = new ArrayList<>();
List<Integer> intList = new ArrayList<>();

System.out.println(stringList.getClass() == intList.getClass());  // true! Both are just ArrayList at runtime

// if (stringList instanceof List<String>) { }  // COMPILE ERROR: illegal generic type check
if (stringList instanceof List<?>) { }  // legal -- only checks the raw type, ignoring the parameter

Common follow-ups: Given type erasure removes runtime generic information from instances, how does reflection still manage to retrieve a field or method's generic signature information?;Why did Java choose erasure over reified generics (like C#'s approach, which does preserve runtime type information)?

// PECS in action: copying from a producer (extends) to a consumer (super)
public static <T> void copy(List<? extends T> source, List<? super T> destination) {
    for (T item : source) {  // safe to READ as T from the producer
        destination.add(item);  // safe to WRITE T into the consumer
    }
}

List<Integer> ints = List.of(1, 2, 3);
List<Number> numbers = new ArrayList<>();
copy(ints, numbers);  // works: List<Integer> extends Number-compatible, List<Number> accepts Integer

Common follow-ups: Why can't you call add() on a List<? extends T> reference, even though the underlying list clearly supports adding elements of its actual concrete type?;How does PECS relate to the broader concept of covariance and contravariance in type systems?

public class Utils {
    public static <T> T firstNonNull(T a, T b) {
        return a != null ? a : b;
    }
}

String result = Utils.firstNonNull(null, "default");  // T inferred as String from the arguments
Integer num = Utils.firstNonNull(5, 10);               // T inferred as Integer

// Explicit type witness syntax, rarely needed but available
String explicit = Utils.<String>firstNonNull(null, "default");

Common follow-ups: What happens when the compiler cannot unambiguously infer a generic method's type parameter from context, and how do you resolve it?;How does target-type inference (introduced/refined in later Java versions) improve on earlier, more limited inference in certain scenarios?

public class Pair<K, V> {
    private final K key;
    private final V value;
    public Pair(K key, V value) { this.key = key; this.value = value; }
    public K getKey() { return key; }
    public V getValue() { return value; }
}

public static <T extends Comparable<T>> T max(List<T> list) {
    T max = list.get(0);
    for (T item : list) {
        if (item.compareTo(max) > 0) { max = item; }  // compareTo() only callable because of the bound
    }
    return max;
}

Common follow-ups: How would you write a bound requiring T to implement multiple interfaces simultaneously (like both Comparable and Serializable)?;What's the difference between a bounded type parameter and a bounded wildcard, given both use the 'extends' keyword?

// Unbounded wildcard: fine when the method genuinely doesn't care about the specific type
public static void printAll(List<?> list) {
    for (Object item : list) { System.out.println(item); }  // only Object-level operations needed
}

// Generic type parameter: needed when relating type across parameters/return value
public static <T> void copyFirst(List<T> source, List<T> destination) {
    destination.add(source.get(0));  // T ties source and destination together meaningfully
}

Common follow-ups: Why can't you call list.add(someObject) on a List<?> reference (besides adding null)?;What's the relationship between List<?> and List<Object> -- are they interchangeable?

// Simplified illustration of ArrayList's internal pattern for this challenge
public class SimpleGenericList<E> {
    private Object[] elements = new Object[10];  // MUST use Object[] internally, can't do new E[10]

    @SuppressWarnings("unchecked")
    public E get(int index) {
        return (E) elements[index];  // unsafe cast, but JDK-author-verified safe given internal invariants
    }
}

Common follow-ups: What specific invariant must be maintained internally to make this unsafe cast pattern actually safe in practice, despite the compiler's unchecked warning?;Why doesn't the JDK just use a List<Object> internally instead of a raw array, avoiding the unsafe cast issue entirely?

public class Stack<T> {
    private final List<T> elements = new ArrayList<>();

    public void push(T item) { elements.add(item); }

    public T pop() {
        if (elements.isEmpty()) throw new NoSuchElementException("Stack is empty");
        return elements.remove(elements.size() - 1);
    }

    public T peek() {
        if (elements.isEmpty()) throw new NoSuchElementException("Stack is empty");
        return elements.get(elements.size() - 1);
    }

    public boolean isEmpty() { return elements.isEmpty(); }
}

Stack<String> stack = new Stack<>();
stack.push("first");
String top = stack.pop();  // returns String directly, no cast needed

Common follow-ups: How would you add a generic bound to this Stack to require elements be Comparable, enabling a max() method?;What's the performance/design trade-off of backing this Stack with an ArrayList versus a raw array with manual resizing?

public class Processor {
    public void process(List<String> strings) { }
    // public void process(List<Integer> integers) { }  // COMPILE ERROR: erasure clash!
    // Both methods erase to identical signature: process(List)

    // Workaround: different method names, since overloading purely on generic type param is impossible
    public void processStrings(List<String> strings) { }
    public void processIntegers(List<Integer> integers) { }
}

Common follow-ups: How would you use a Class<T> token parameter combined with runtime type checking to achieve similar dispatch behavior despite this overload restriction?;Why doesn't this same erasure-clash restriction apply to methods differing by a non-generic parameter type?

List rawList = new ArrayList();  // raw type -- compiles, but loses ALL generic type safety
rawList.add("hello");
rawList.add(42);  // no compile-time error at all, unlike a properly parameterized List<String>

// Generates an "unchecked" compiler warning
@SuppressWarnings("unchecked")
List<String> unsafeCast = rawList;  // legal but genuinely unsafe if rawList actually contains mixed types

Common follow-ups: What specific unchecked warnings does the compiler generate when working with raw types, and why should they never be silently ignored?;How does mixing raw types and generic types in the same codebase create particularly confusing type-safety holes?