6.1 Generic Classes, Interfaces, Methods, and Type Erasure

6.1 Generic Classes, Interfaces, Methods, and Type Erasure

Prior to Java 5, collections operated exclusively on raw Object references. Developers were required to perform explicit casting upon retrieval, exposing applications to runtime ClassCastException failures that compilers could not detect. Generics introduced compile-time type safety by allowing classes, interfaces, records, and methods to parameterize over types. The Oracle Java SE 17 Developer certification (1Z0-829) tests not only basic declaration syntax, but also the underlying bytecode mechanics of type erasure, synthetic bridge methods, and the rigid architectural boundaries where generics cannot be used.

---

Declaring Generic Types

Generic classes, interfaces, and records declare one or more formal type parameters enclosed in angle brackets (<T>) immediately following the type identifier.

// Generic Class
public class Container<T> {
    private T content;
    public Container(T content) { this.content = content; }
    public T getContent() { return content; }
    public void setContent(T content) { this.content = content; }
}

// Generic Record (Java 16+)
public record KeyValue<K, V>(K key, V value) {}

// Generic Interface
public interface Repository<T, ID> {
    T findById(ID id);
    void save(T entity);
}

By convention, single uppercase letters serve as type parameter names:

• E: Element (extensively used by the Java Collections Framework)
• K: Key (used in maps)
• V: Value (used in maps and key-value pairs)
• N: Number
• T: Type (general-purpose first type parameter)
• S, U, V: 2nd, 3rd, and 4th type parameters

Subtyping and Implementing Generic Interfaces

A subtype can resolve or retain generic parameters when extending a generic superclass or implementing a generic interface:

// 1. Concrete implementation: fixes type arguments to concrete types
public class CustomerRepository implements Repository<String, Long> {
    public String findById(Long id) { return "Customer-" + id; }
    public void save(String entity) { /* persist */ }
}

// 2. Generic implementation: preserves or expands type parameters
public class RelationalRepository<E, I> implements Repository<E, I> {
    public E findById(I id) { return null; }
    public void save(E entity) { /* persist */ }
}

---

Generic Methods and Type Witnesses

Generic methods introduce their own formal type parameters independent of whether the enclosing class is generic. The type parameter declaration must appear immediately before the return type.

public class TransformationUtils {
    // Non-generic class declaring a static generic method
    public static <T, R> R transform(T input, java.util.function.Function<T, R> mapper) {
        return mapper.apply(input);
    }

    // Instance generic method
    public <E> void inspectElement(E element) {
        System.out.println(element.getClass().getName() + ": " + element);
    }
}

Type Parameter Positioning Rules

The placement of formal type parameters in method headers is a frequent source of exam traps:

// VALID: <T> precedes return type T
public <T> T identity(T item) { return item; }

// COMPILE ERROR: missing <T> before return type T
// public T invalidIdentity(T item) { return item; } 

// COMPILE ERROR: type parameter placed after return type
// public T <T> wrongPlacement(T item) { return item; }

Type Witnesses

When invoking a generic method, the compiler generally infers the type argument from context or method parameters. However, developers can provide an explicit type witness to remove ambiguity. The type witness appears in angle brackets immediately before the method name:

// Compiler inference
String result1 = TransformationUtils.transform(100, val -> "Value: " + val);

// Explicit type witness syntax on static call
String result2 = TransformationUtils.<Integer, String>transform(100, val -> "Value: " + val);

// Explicit type witness syntax on instance call
TransformationUtils utils = new TransformationUtils();
utils.<String>inspectElement("Hello Java 17");

// Explicit type witness on this/super
// this.<String>inspectElement("Local");

---

The Mechanics of Type Erasure

Java implements generics via type erasure to preserve full backward compatibility with pre-existing bytecode. The Java compiler inspects type parameters at compile time for correctness, then strips the type arguments during bytecode generation.

Type erasure performs three operations:

1. Bound Replacement: Replaces all type parameters with their first bound. Unbounded parameters (<T>) become java.lang.Object. Bounded parameters (<T extends Number>) become java.lang.Number. Multiple bounds (<T extends Number & Comparable<T>>) become the leftmost bound (Number).
2. Synthetic Casts: Inserts synthetic checkcast instructions at call sites where generic data is retrieved.
3. Synthetic Bridge Methods: Generates synthetic bridge methods in subclasses to preserve polymorphism when method signatures diverge after erasure.

Bytecode Translation Example

// Source Code written by developer:
public class Storage<T extends Number> {
    private T data;
    public void set(T data) { this.data = data; }
    public T get() { return this.data; }
}

// Bytecode equivalent generated by javac:
public class Storage {
    private Number data; // Replaced with bound Number
    public void set(Number data) { this.data = data; }
    public Number get() { return this.data; }
}

When accessing get() from a parameterized call site:

Storage<Integer> store = new Storage<>();
store.set(42);
Integer val = store.get(); // javac inserts bytecode: (Integer) store.get();

Synthetic Bridge Methods

Consider a class implementing a generic interface with a concrete type argument:

public interface Consumer<T> {
    void accept(T item);
}

public class StringConsumer implements Consumer<String> {
    @Override
    public void accept(String item) {
        System.out.println(item.toLowerCase());
    }
}

Under type erasure, Consumer.accept becomes accept(Object item). However, StringConsumer defines accept(String item). Because String and Object are distinct parameter types in JVM method descriptors, StringConsumer would not override Consumer.accept(Object). To guarantee polymorphic dispatch, the compiler synthesizes a hidden bridge method in StringConsumer:

// Synthetic bridge method generated by javac in StringConsumer:
public void accept(Object item) {
    this.accept((String) item); // Delegates to the specific method
}

---

Absolute Restrictions and Limitations of Generics

Because generic types do not exist at runtime, the compiler strictly enforces the following architectural limitations:

---

Raw Types and Unchecked Warnings

A raw type is the name of a generic class or interface used without type arguments (e.g., List instead of List<String>). Raw types exist solely for backward compatibility with pre-Java 5 code.

Using raw types bypasses generic compiler checks and generates unchecked compiler warnings:

List<String> names = new ArrayList<>();
names.add("Duke");

// Raw type reference pointing to generic list
List rawList = names; 
rawList.add(100); // Unchecked call warning: adds Integer to List<String>!

// Runtime failure at the retrieval point:
// javac inserted a synthetic cast (String) on names.get(1)
String name = names.get(1); // Throws ClassCastException: Integer cannot be cast to String!

Notice that the ClassCastException occurs upon retrieval from the parameterized list, not when the invalid element is added through the raw reference. Always avoid raw types in modern Java code.