Невозможно реализовать интерфейс с разными аргументами типа

Question

У меня есть общий интерфейс A<T>, у меня есть класс B, который реализует A<String>. Я создал класс C, который расширяет B и реализует A<Number>. Для C, я получаю высказывание об ошибке компиляции:

A cannot be inherited with different type arguments <String> and <Number>.

Почему это не разрешено? Если ответ на это - стирание типа, то, пожалуйста, объясните подробно.

Пример кода:

public interface A<T> { 

} 

public class B implements A<String> { 

} 

public class C extends B implements A<Number> { 
} 

Answer 1

Это не имело бы смысла, если бы вы могли, если честно.

Вот сценарий:

• B реализует A и связывает A<T> к A<String>.
• C наследует от B (который уже обязан A<String>), и вы пытаетесь также реализовать A<Number>.

Вы не можете использовать тип в обоих направлениях.

Если вы хотите включить Number как-то в C, то вы будете иметь тип наC и не только на A.

будет скомпилирован, но это будет выглядеть странно:

public class C<T> extends B implements A<String> { 

} 

В конечном счете это действительно сводится к тому, как иерархия должна быть изложены. Если вы действительно нужна связь между B и C, тогда нет смысла конкретизировать их типы таким образом; просто используйте их вместо T. Наконец, в силу наследования у вас все еще есть доступ к общему договору A по B в C, поэтому вам не нужно его реализовывать.

public interface A<T> { 


} 

public class B<T> implements A<T> { 

} 

public class C<T> extends B<T> { 

} 

Answer 2

Язык Спецификация Java в §8.1.5 состояний следующие:

Класс не может одновременно быть подтипом двух типов интерфейсов , которые разные параметризация одного и того же общего интерфейс (§9.1.2) или подтип параметризации общего интерфейса и необработанный тип, называющий тот же общий интерфейс, или ошибка времени компиляции .

Это требование было введено для того, чтобы поддержать перевода от типа стирания (§4.6).

Это означает, что после стирания ваш класс может закончиться методами (если он есть) с той же подписью. Более подробную информацию см. В статье Angelika Langer's site.