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

Статический член принадлежит самому классу, а не конкретному объекту или конкретной параметризации. Поэтому у него нет однозначного значения параметра типа: один и тот же статический член существует для всех вариантов GenericClass<String>, GenericClass<Integer> и других. Для статического метода нужно объявить собственный параметр типа.

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

Обобщённые типы появились в Java 5, чтобы добавить проверку типов на этапе компиляции и уменьшить необходимость в приведениях типов. При этом Java сохранила совместимость с существующим кодом, поэтому generics реализованы преимущественно через стирание типов.

После компиляции параметризация класса не создаёт отдельную версию класса для каждого аргумента типа. Следовательно, статические члены не могут физически существовать отдельно для каждой параметризации.

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

Параметр типа класса описывает состояние и поведение конкретной параметризации экземпляров. Например, Box<String> и Box<Integer> имеют разные логические типы содержимого, хотя после стирания используют один класс Box.

Статический член общий для класса. Если разрешить ему использовать параметр типа класса, возникла бы неоднозначность: какой тип должен иметь одно общее статическое поле — String, Integer или другой тип? Это привело бы к конфликтам между разными параметризациями и нарушению типобезопасности.

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

Параметр типа класса доступен нестатическим членам, поскольку они работают в контексте конкретного экземпляра. Статические члены такого контекста не имеют, поэтому напрямую ссылаться на параметр типа класса им запрещено.

class Box<T> {
    private T value;

    T getValue() {
        return value;
    }

    static <U> U identity(U value) {
        return value;
    }
}

В примере value и getValue используют T, потому что относятся к объекту конкретного Box<T>. Метод identity допустим, поскольку объявляет собственный параметр типа U; он не использует параметр T класса.

Это ограничение относится не только к полям, но и к статическим методам, статическим блокам и другим статическим контекстам. Объявление собственного параметра метода — безопасный способ сделать статический метод обобщённым.

Нельзя обойти ограничение заменой T на Object, если требуется типобезопасность: это устранит связь между входным и возвращаемым типом. Можно явно передать Class<T> или использовать отдельный параметр метода, но тогда тип должен поступать из аргументов или явного контекста вызова.

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

Команда разрабатывает обобщённый Repository<T> и хочет добавить статический кэш последнего значения типа T. Вариант с общим статическим полем концептуально неверен: один кэш оказался бы общим для всех T, а тип поля нельзя выбрать одновременно как User и Order.

Рассматривались три решения. Хранить кэш в нестатическом поле просто и типобезопасно, но состояние будет отдельным у каждого экземпляра. Хранить значения в Map<Class<?>, Object> позволяет иметь общий кэш, но требует ключа типа, проверок и аккуратного контроля приведений. Сделать статический обобщённый метод удобно для операций без состояния, но он не решает задачу общего кэша.

Выбранный вариант — нестатическое поле для кэша репозитория. Он сохраняет типобезопасность и явно связывает состояние с конкретной параметризацией. Если общий кэш действительно необходим, его выносят в отдельный компонент и проектируют его API вокруг явного ключа типа, а не пытаются использовать T в статическом контексте.

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

Может ли статический метод обобщённого класса использовать параметр типа, если он ничего не хранит?

Нет, параметр T, объявленный у класса, всё равно недоступен статическому методу. Отсутствие состояния не меняет правило: статический метод не связан с экземпляром и не знает, какая параметризация класса подразумевалась.

Однако метод может объявить собственный параметр, например <U> U convert(U value). Это другой параметр типа: он принадлежит методу, выводится из его аргументов и существует только в рамках конкретного вызова.

Почему нельзя считать, что для каждой параметризации автоматически создаётся отдельная копия статического поля?

Потому что в Java параметризация не создаёт новые runtime-классы. GenericClass<String> и GenericClass<Integer> используют один объект Class для исходного класса после стирания типов, поэтому статическое поле физически одно.

Такое разделение можно реализовать самостоятельно, например через внешнее хранилище с ключом Class<?>, но это уже логика приложения, а не поведение generics. Она также не гарантирует безопасность сама по себе: соответствие ключа и значения нужно поддерживать явно.

Может ли статический вложенный класс использовать параметр типа внешнего обобщённого класса?

Нет. Статический вложенный класс не связан с экземпляром внешнего класса и не получает его параметр типа. Если ему нужна параметризация, он должен объявить собственный параметр, например static class Entry<U>.

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