Basics

Generic classes, generic methods, bounded type parameters, and the design mindset behind reusable, type-safe APIs.

1. Definition

What is it?

Java generics let you describe algorithms and data structures in terms of type parameters instead of concrete classes.

Instead of writing one container for String, another for Integer, and a third for User, you write one generic API and let the caller bind the actual type.

The compiler then checks whether the chosen type is used consistently.

This is why a List<String> can reject an Integer at compile time without any runtime check in your own code.

Why does it exist?

Before generics, Java collections stored Object references.

That made APIs flexible, but unsafe.

Developers had to cast values back manually.

Those casts were noisy, easy to forget, and often failed only at runtime.

Generics were introduced to solve three recurring engineering problems:

• reduce unsafe casts
• move errors from runtime to compile time
• enable reusable libraries without losing readability

Where does it fit?

Generics sits in the overlap of language design, API design, and day-to-day coding style.

It is fundamental for:

• collections such as List<T>, Map<K, V>, Optional<T>
• utility APIs such as Collections.sort, Comparator<T>, Stream<T>
• framework abstractions such as repositories, converters, serializers, and event handlers

In interviews, generics is not only about syntax.

It is a signal that you understand type safety, library design, and how Java balances backward compatibility with developer ergonomics.

2. Core Concepts

2.1 Generic classes

2.1.1 Keywords and contracts you should name explicitly here

This topic is not only about syntax. These words describe the core contracts of Java generics and should be stated precisely:

• type parameter — the placeholder declared by the API author, for example T in Box<T>.
• type argument — the concrete type supplied by the caller, for example String in Box<String>.
• generic class — a class whose contract depends on one or more type parameters.
• generic method — a method that declares its own type parameter independently of the class.
• bound — a restriction on allowed types, for example <T extends Number>.
• multiple bounds — combining several requirements, for example <T extends Number & Comparable<T>>.
• raw type — legacy use of a generic type without type arguments, which weakens type safety.
• unchecked warning — a signal that the compiler can no longer prove full type correctness.
• diamond operator — the <> shorthand that lets the compiler infer type arguments in constructors.

In interviews, it is stronger to say “this API introduces a type parameter with an upper bound” than to say only “it uses generics”.

A generic class introduces one or more type parameters at the class level.

public final class Box<T> {
    private T value;

    public Box(T value) {
        this.value = value;
    }

    public T get() {
        return value;
    }

    public void set(T value) {
        this.value = value;
    }
}

T is a placeholder.

The caller chooses the concrete type when using the class.

Box<String> messageBox = new Box<>("hello");
Box<Integer> answerBox = new Box<>(42);

The important design idea is that the class logic stays the same while the compiler tracks type correctness for each use site.

2.2 Generic methods

A generic method declares its own type parameter on the method itself.

It does not need the surrounding class to be generic.

public final class MoreCollections {
    public static <T> T first(List<T> items) {
        if (items.isEmpty()) {
            throw new IllegalArgumentException("items must not be empty");
        }
        return items.get(0);
    }
}

<T> belongs to the method, not to the class.

This distinction is frequently asked in interviews.

2.3 Bounded type parameters

Sometimes any type is too permissive.

You want reuse, but only for a family of types.

Then you add an upper bound.

public static <T extends Number> double sum(List<T> numbers) {
    double total = 0.0;
    for (T number : numbers) {
        total += number.doubleValue();
    }
    return total;
}

The bound says:

• callers may use Integer, Long, Double, and other Number subtypes
• inside the method you may call Number methods on T

This is an API contract.

It communicates both capability and restriction.

2.4 Multiple bounds

Java also supports multiple bounds for type parameters.

public static <T extends Number & Comparable<T>> T max(T left, T right) {
    return left.compareTo(right) >= 0 ? left : right;
}

The first bound may be a class.

Any additional bounds must be interfaces.

This matters when designing algorithms that need multiple capabilities from the same type.

2.5 Raw types

A raw type is the legacy, non-parameterized use of a generic type.

List raw = new ArrayList();
raw.add("hello");
raw.add(42);

Raw types exist mainly for backward compatibility with pre-generics Java.

They disable most of the compile-time guarantees that generics are supposed to provide.

Use them only when you are forced to interact with legacy APIs.

In modern code, a raw type is a smell.

2.6 Type inference

The compiler can often infer generic types from context.

Map<String, Integer> scores = new HashMap<>();
var names = List.of("Ada", "Linus", "Grace");

This reduces ceremony.

But inference is only a convenience feature.

It should not make code harder to read.

If the inferred type is non-obvious, explicit generic parameters can still be the better choice.

2.7 Common type parameter names

These are conventions, not laws.

Good naming improves comprehension, especially in larger generic signatures.

2.8 What generics does and does not guarantee

Generics guarantees compile-time type checking for parameterized uses.

Generics does not magically preserve full runtime type information.

That boundary becomes critical later in type erasure discussions.

For basics, remember the core promise:

• safer APIs
• fewer explicit casts
• better intent in the type system

3. Practical Usage

Designing containers and wrappers

Generic classes are ideal when the behavior is identical across many types.

Examples:

• Result<T> for service outcomes
• Page<T> for pagination
• Pair<L, R> for small utility abstractions
• CacheEntry<K, V> for infrastructure code

The rule of thumb is simple.

If the code changes only because the stored type changes, generics is a good fit.

Designing utility methods

Generic methods are better when the class itself should stay non-generic.

Examples:

• finding the first element
• swapping two values in a list
• converting a list into a map using mapper functions

That keeps the generic scope as small as possible.

Smaller scope usually means simpler APIs.

Building service-layer abstractions

In application code, generics often appear in reusable infrastructure rather than in business logic itself.

Examples:

• Repository<T, ID>
• Mapper<S, T>
• Validator<T>
• EventHandler<T>

This is useful because the framework logic stays reusable while the domain type varies.

Choosing between generic abstraction and concrete API

Do not make everything generic by default.

A good interview answer mentions this explicitly.

Prefer a concrete type when:

• the API is domain-specific and only one type truly makes sense
• a generic abstraction would hide useful business semantics
• the generic signature would become harder to read than the concrete version

Prefer a generic abstraction when:

• the same logic is repeated across multiple types
• the behavior depends on capabilities, not on one concrete class
• the generic type communicates stronger intent to callers

Bounded generics in real code

Bounded type parameters are common when algorithms depend on a shared capability.

Examples:

• values must be comparable
• values must be numeric
• values must implement a framework interface

The bound should represent a real requirement.

If you add extends only because you think “constraints look advanced,” the design is probably wrong.

API design checklist

When designing a generic API, ask:

1. What varies: the stored type, the behavior, or both?
2. Does the caller gain real type safety from parameterization?
3. Would a concrete type be clearer than a generic one?
4. Are bounds expressing actual capability requirements?
5. Will the signature still be understandable for the next maintainer?

Interview framing

If asked “when would you use generics?”, a strong answer sounds like this:

I use generics when the behavior is stable but the participating type varies, and I want the compiler to enforce the contract instead of relying on Object plus casts.

That answer is stronger than merely saying “for reusability.”

4. Code Examples

Example 1 — Generic wrapper type

public final class Result<T> {
    private final T value;
    private final String error;

    private Result(T value, String error) {
        this.value = value;
        this.error = error;
    }

    public static <T> Result<T> success(T value) {
        return new Result<>(value, null);
    }

    public static <T> Result<T> failure(String error) {
        return new Result<>(null, error);
    }

    public boolean isSuccess() {
        return error == null;
    }

    public T getValue() {
        return value;
    }
}

This pattern appears in many codebases.

The generic parameter expresses the successful payload type.

Example 2 — Generic method

public final class Lists {
    public static <T> T last(List<T> items) {
        if (items.isEmpty()) {
            throw new IllegalArgumentException("items must not be empty");
        }
        return items.get(items.size() - 1);
    }
}

This is the classic example where the class itself does not need to be generic.

Example 3 — Upper bound

public final class MathUtil {
    public static <T extends Number> double average(List<T> numbers) {
        if (numbers.isEmpty()) {
            throw new IllegalArgumentException("numbers must not be empty");
        }

        double total = 0;
        for (T number : numbers) {
            total += number.doubleValue();
        }
        return total / numbers.size();
    }
}

The bound documents why the algorithm works.

It needs the Number API.

Example 4 — Multiple bounds

public final class Comparisons {
    public static <T extends Number & Comparable<T>> T larger(T left, T right) {
        return left.compareTo(right) >= 0 ? left : right;
    }
}

This is useful when one type must satisfy more than one contract.

Example 5 — Raw type pitfall

List raw = new ArrayList();
raw.add("text");
raw.add(123);

List<String> names = raw;
String first = names.get(1); // runtime ClassCastException

The compiler will warn you.

The warning matters.

Unchecked operations are often a delayed production bug.

5. Trade-offs

The key lesson is that generics is not free abstraction.

It is valuable abstraction.

That distinction matters.

If a generic signature becomes too clever, it stops helping.

6. Common Mistakes

1. Using raw types in modern code

Raw types erase the main benefit of generics.

They usually indicate legacy interop or careless code.

2. Making the whole class generic when only one method needs it

This spreads complexity unnecessarily.

Keep the generic scope as small as possible.

3. Adding bounds without a real capability need

<T extends Serializable> is only justified if serialization is actually required.

Otherwise the bound is noise.

4. Confusing `List