Generics

public abstract class Builder<T extends Builder<T>> {
    protected String name;
    @SuppressWarnings("unchecked")
    public T withName(String name) { this.name = name; return (T) this; }  // returns concrete subclass type T
}

public class CarBuilder extends Builder<CarBuilder> {
    private int wheels;
    public CarBuilder withWheels(int wheels) { this.wheels = wheels; return this; }
}

CarBuilder car = new CarBuilder().withName("Tesla").withWheels(4);  // chaining works across base AND subclass methods seamlessly

Common follow-ups: What happens if a subclass forgets to correctly parameterize itself (e.g., extends Builder<SomeOtherBuilder> by mistake)?;Why is the unchecked cast to (T) inside the base class considered safe in this specific, well-established pattern?

public static <T> T parseJson(String json, Class<T> type) {
    // 'type' provides the runtime type information T alone cannot supply due to erasure
    return someJsonLibrary.readValue(json, type);
}

User user = parseJson(jsonString, User.class);  // Class<User> token supplies what erasure removed

public static <T> T createInstance(Class<T> type) throws Exception {
    return type.getDeclaredConstructor().newInstance();  // reflection-based instantiation using the token
}

Common follow-ups: What's the more advanced 'super type token' technique (using an anonymous subclass) for recovering even more complex generic type information (like List<String> specifically, not just List)?;Why can't the method simply use T.class directly instead of requiring an explicit Class<T> parameter?

// Arrays: covariant, but unsafe -- fails at RUNTIME
Object[] objArray = new String[3];
objArray[0] = 42;  // compiles, throws ArrayStoreException at runtime

// Generics: invariant by default, safe -- fails at COMPILE time instead
// List<Object> objList = new ArrayList<String>();  // COMPILE ERROR, caught immediately

// Generics with bounded wildcard: opt-in controlled covariance, STILL compile-time safe
List<? extends Object> objList2 = new ArrayList<String>();  // legal
// objList2.add("test");  // COMPILE ERROR -- can't write to a ? extends reference, still safe!

Common follow-ups: Why did the language designers choose different variance defaults for arrays versus generics, given both existed under the same type system?;What would Java generics look like if they had been designed to be covariant by default, similar to arrays?

public interface Repository<T, ID> {
    T findById(ID id);
    List<T> findAll();
    T save(T entity);
    void deleteById(ID id);
}

public class UserRepository implements Repository<User, Long> {
    public User findById(Long id) { /* ... */ return null; }
    public List<User> findAll() { /* ... */ return List.of(); }
    public User save(User user) { /* ... */ return user; }
    public void deleteById(Long id) { /* ... */ }
}

Common follow-ups: How does Spring Data JPA build heavily on exactly this generic repository interface pattern to auto-generate implementations?;What's the benefit of parameterizing the ID type separately from the entity type T, rather than assuming a fixed ID type?

public class Pair<A, B> {
    private final A first;
    private final B second;
    private Pair(A first, B second) { this.first = first; this.second = second; }
    public static <A, B> Pair<A, B> of(A first, B second) { return new Pair<>(first, second); }
}

// Target-type inference determines A=String, B=Integer purely from the assignment context
Pair<String, Integer> pair = Pair.of("age", 30);

Common follow-ups: What specific Java version introduced meaningfully improved target-type inference, and what scenarios did it newly support?;How does this inference interact with method overloading when multiple overloads could each plausibly match?