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

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

interface Handler<T> {
    void handle(T value);
}

// Ошибка компиляции:
// один и тот же интерфейс унаследован с разными аргументами типа
class Invalid implements Handler<String>, Handler<Integer> {
    public void handle(String value) {}
    public void handle(Integer value) {}
}

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

Generics появились в Java как способ добавить проверку типов и повторно использовать коллекции и API без постоянных приведений типов. При этом Java сохранила совместимость с существующим байткодом и библиотеками, поэтому обобщения реализованы в основном через стирание типов, а не через отдельные runtime-версии каждого параметризованного класса.

Из-за этого параметризация интерфейса доступна компилятору, но обычно не существует как отдельный тип на уровне JVM. Ограничение на разные параметризации одного интерфейса предотвращает конфликты, которые стирание типов не может разрешить.

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

Рассмотрим два контракта: обработчик строк и обработчик целых чисел. На уровне исходного кода кажется возможным объявить два метода с разными параметрами, но после стирания оба метода имеют форму обработки значения типа Object.

Если бы такая конструкция разрешалась, один объект формально имел бы два несовместимых экземпляра одного интерфейса. Компилятору пришлось бы решить, какой метод считать реализацией общего стёртого метода, а JVM не могла бы выбрать обработчик по аргументу типа: параметризация в runtime не участвует в диспетчеризации методов.

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

Для Handler<String> метод handle(T) после подстановки имеет параметр String. Для Handler<Integer> он имеет параметр Integer. Однако стирание параметра T даёт Object, поэтому оба контракта требуют один и тот же стёртый метод handle(Object).

Проблема возникает не только при непосредственном объявлении двух интерфейсов. Она также возникает, если разные параметризации одного интерфейса приходят через разные базовые классы или интерфейсы: итоговый класс всё равно наследует конфликтующие варианты одного generic-типа.

Bridge-методы не устраняют ограничение. Компилятор может создавать bridge-метод, например для сохранения переопределения после стирания, но два bridge-метода с одинаковым именем и одинаковой стёртой сигнатурой не дают JVM способа различать String и Integer как аргументы типа.

Практические варианты решения:

использовать один параметр типа класса, если обработчики должны быть согласованного типа;
дать двум ролям разные имена интерфейсов, если они действительно независимы;
применить композицию: хранить внутри класса два объекта Handler с разными параметризациями и делегировать им вызовы;
использовать общий нетипизированный контракт только на границе системы, принимая unchecked-проверки и потерю статической безопасности.

Последний вариант обычно хуже: raw-типы позволяют обойти часть проверок компилятора, но переносят риск ошибки типов на runtime и могут привести к ClassCastException.

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

Допустим, объект должен отдельно обрабатывать текстовые команды и числовые события. Попытка реализовать два Handler в одном классе запрещена из-за конфликта стираемых сигнатур.

Разделение на два именованных интерфейса устраняет конфликт и делает роли явными, но увеличивает число типов API. Использование raw-интерфейса уменьшает количество объявлений, однако лишает код типобезопасности и затрудняет сопровождение.

На практике обычно выбирают композицию: класс получает Handler<String> и Handler<Integer> в разных полях и делегирует каждому объекту свой тип событий. Такое решение сохраняет статическую проверку, не зависит от runtime-параметризации и явно моделирует две независимые обязанности.

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

Запрещена ли реализация одного интерфейса через один параметр типа?

Нет. Класс может реализовать Handler<T> один раз, объявив собственный параметр типа, например Handler<T>. Это создаёт один согласованный контракт: внутри класса T обозначает один и тот же тип. Запрет относится к нескольким несовместимым параметризациям одного и того же generic-интерфейса.
Можно ли обойти ограничение, реализовав интерфейс как raw-тип?

Raw-тип иногда позволяет подавить часть проверок и получить предупреждения компилятора, но он не превращает класс в безопасную реализацию одновременно Handler<String> и Handler<Integer>. Параметризация теряется, а ошибки совместимости могут проявиться только при выполнении. Такой подход допустим лишь на специально изолированной границе совместимости, но не как нормальная модель API.
Почему разные методы handle(String) и handle(Integer) не могут решить проблему?

В исходном Java-коде это выглядят как перегруженные методы. После стирания оба должны иметь сигнатуру handle(Object), а методы нельзя перегрузить только различием, которое исчезает после стирания. Кроме того, JVM не выбирает метод по generic-аргументу: выбор перегрузки выполняется компилятором, тогда как параметризация интерфейса не сохраняется как критерий runtime-диспетчеризации.