Краткий ответ

Class<T> служит явным токеном типа: он передаёт в обобщённый код информацию о конкретном классе, сохранившуюся во время выполнения. С его помощью можно выполнить проверку и приведение через cast, не прибегая к неконтролируемому приведению к T.

При этом Class<T> не восстанавливает стёртый параметр обобщённого типа: он описывает класс String, ArrayList или другой конкретный тип, но не различает, например, List<String> и List<Integer>.

Исторический контекст

Обобщения Java проектировались со стиранием типов, чтобы параметризованный код сохранял совместимость с существующим байткодом и библиотеками. Поэтому параметр T доступен компилятору, но обычно отсутствует как отдельный объектный тип во время выполнения.

Многие API, однако, должны выполнять динамическую проверку: читать конфигурацию, десериализовать значение, извлекать объект из контейнера или создавать экземпляр. Class<T> решает эту проблему за счёт явной передачи метаинформации о конкретном классе.

Постановка проблемы

Обобщённый метод может гарантировать согласованность типов на этапе компиляции, но сам по себе не знает, какой именно T требуется во время выполнения. Если значение пришло из Object, контейнера или внешнего источника, прямое приведение к T невозможно надёжно проверить: после стирания T не является доступным классом для оператора приведения.

Неконтролируемое приведение может скрыть ошибку до места фактического использования объекта. В результате проблема проявится позднее в виде ClassCastException, а компилятор не сможет предупредить о ней в точке получения данных.

Подробное решение

Параметр Class<T> связывает объект-маркер класса с параметром T на уровне сигнатуры метода. Метод принимает значение типа Class<T>, а вызов с String.class выводит T как String.

Метод Class.cast проверяет объект во время выполнения и возвращает его как T. При несовпадении типов он выбрасывает ClassCastException непосредственно в точке проверки, а не позже при использовании результата.

public class TypeTokenDemo {
    static <T> T convert(Object value, Class<T> type) {
        return type.cast(value);
    }

    public static void main(String[] args) {
        String text = convert("hello", String.class);
        System.out.println(text.length());
    }
}

В этом примере String.class одновременно задаёт ожидаемый тип для компилятора и предоставляет объект, способный выполнить проверку во время выполнения. При передаче объекта другого класса type.cast завершится исключением.

Важное ограничение связано с параметризованными типами. Выражение List<String>.class в Java недопустимо, поэтому Class<T> не может проверить тип элементов списка. List.class проверит только, что объект является списком, но не подтвердит, что его элементы имеют тип String.

Таким образом, Class<T> хорошо подходит для конкретных reifiable-типов, доступных во время выполнения. Для описания вложенной параметризации требуется отдельное представление типа, например объект, хранящий структуру параметров, а не только Class.

Ситуация из практики

Сервис конфигурации хранит значения как Object, а потребитель запрашивает параметр с ожидаемым типом. Возможны три подхода.

Прямое приведение к нужному типу короткое, но не даёт локальной проверки и может потребовать неконтролируемого приведения.
Возврат только Object переносит проверку на каждого потребителя и ухудшает типобезопасность API.
Передача Class<T> позволяет централизовать проверку и вывести тип результата из аргумента.

Для строк, чисел, DTO и других конкретных классов выбирается третий вариант: он даёт типизированный результат и раннее обнаружение ошибки. Если конфигурация должна проверять, например, List<String>, одного Class<T> недостаточно; нужен отдельный описатель полного типа и проверка содержимого списка.

Что кандидаты часто упускают

1. Проверяет ли Class<T> только точное совпадение класса?

Нет. Class.cast допускает объект экземпляра указанного класса или его наследника, как обычное проверяемое приведение к базовому типу. Поэтому Number.class может успешно привести объект Integer к Number.

2. Почему нельзя передать Class<List<String>>?

Потому что параметр String стёрт во время выполнения, а литерал класса описывает только реально представимый класс List. List.class имеет тип Class<List>, но не содержит информации о типе элементов; для полного описания нужен иной объект метаданных типа.

3. Устраняет ли Class<T> все неконтролируемые приведения?

Нет. Он безопасно проверяет сам объект T, но не внутреннее содержимое обобщённого объекта. Проверка List.class.cast(value) подтверждает, что значение является списком, однако не проверяет тип каждого элемента. Для List<String> необходима дополнительная поэлементная проверка или специализированный механизм описания и валидации полного типа.