Как стирание ручек переопределяет сценарии в Java?

Question

Этот вопрос относится к моему предыдущему сообщению в here.. Прежде чем я опубликую свой вопрос, я вставляю содержимое из oracle docs;

8.4.8.1. Overriding (by Instance Methods) 

An instance method m1, declared in class C, overrides another instance method m2, declared in class A iff all of the following are true: 

    C is a subclass of A. 

    The signature of m1 is a subsignature (§8.4.2) of the signature of m2. 

8.4.2. Method Signature 
The signature of a method m1 is a subsignature of the signature of a method m2 if either: 

    m2 has the same signature as m1, or 

    the signature of m1 is the same as the erasure (§4.6) of the signature of m2. 

Мое понимание type erasure когда overriding участвует выглядит следующим образом: если после erasure, то signature of m1 and m2 такие же, то тогда они считаются overridden. так в моем предыдущем посте выше я попытался overrideparent class method, который принимает List<String> по subclass method, который принимает List<Integer> предполагая после type erasure , что осталось только List<Object>. но это неправильно. поэтому мое понимание вышеуказанного определения метода overriding, когда вовлечено erasure, является абсолютно неправильным. может кто-нибудь дать простой пример , чтобы объяснить вышеприведенную точку.

Спасибо. btw приведенные выше пункты взяты из here.

Answer 1

Независимо от того, переопределяет ли метод другой, речь идет не только о стираниях методов. Компилятор определяет, переопределяет ли метод другой, и имеет доступ к параметрам типового типа, которые задействованы до того, как произойдет стирание типа.

Ваши мысли об использовании стирания для определения переопределений не совсем правильны. Давайте добавим следующее JLS Section, 8.4.8.1, к обсуждению:

Метод экземпляра m1, объявленный в классе C, перекрывает другой метод экземпляра м2, объявленный в классе A тогда и только тогда все следующие условия:

• C является подклассом A.

• Подпись m1 является подзаголовкой (§8.4.2) подписи m2.

• Либо:

  • м2 являются открытым, защищенным, или объявленным с доступом по умолчанию в том же пакете, C или

  • m1 переопределяет метод м3 (м3 отличающихся от m1, m3 отличная от m2), такая, что m3 переопределяет m2.

Это необходимо, чтобы m1 является подсигнатурой m2, но не наоборот.

Пример 1:

class A { 
    public void foo(List<String> list) { } 
} 

class B extends A { 
    @Override 
    public void foo(List list) {} 
} 

Это является законным, потому что подпись B «foo метода с такой же, как стирание A» foo метода с.

Пример 2:

class A { 
    public void foo(List list) { } 
} 

class B extends A { 
    @Override 
    public void foo(List list) {} 
} 

Это является законным, так как подписи являются одинаковыми (даже если они являются сырые).

Пример 3:

class A { 
    public void foo(List list) { } 
} 

class B extends A { 
    @Override 
    public void foo(List<Integer> list) {} 
} 

Это не законно, так как стирание наиважнейшей метода не принимается во внимание. То есть List<Integer> сравнивается с стиранием List, который по-прежнему остается List, и они не то же самое.

Пример 4:

class A { 
    public void foo(List<String> list) { } 
} 

class B extends A { 
    @Override 
    public void foo(List<Integer> list) {} 
} 

Это опять не законно, так как стирание наиважнейшей метода не принимается во внимание. То есть List<Integer> сравнивается с стиранием List<String> (List), и они не то же самое.

Вы не можете изменить параметры типового типа параметров в методе переопределения (например,List<String> - List<Integer>. Вы не можете ввести дженерики при переопределении метода, который не использовали генерики (например, (List к List<Integer>). Тем не менее, вы можете удалить дженерики при переопределении (например, List<String> к List).

Answer 2

Поскольку Java является строго типизированным языком, он должен быть осторожным в отношении ковариации и того, как типы работают вместе. Erasure не является оправданием для нарушения правил типа.

Например:

class BaseGood<T> { 
    public void doStuff(T elem) { 
       // ... 
    } 
} 
class DerivedGood<T> extends BaseGood { 
    public void doStuff(Object elem) { 
     super.doStuff(elem); 
    } 
} 
class BaseBad { 
    public void doStuff(List<Double> list) { 
     // ... 
    } 
} 
class DerivedBad extends BaseBad { 
    public void doStuff(List<Integer> list) { 
     super.doStuff(list); 
     // ... 
    } 
} 

Здесь мы имеем два различных случая для стирания.

С BaseGood и DerivedGood классов, оба метода имеют один и тот же стирание: void doStuff(Object elem), и это может быть известно, что T всегда будет иметь тип Object и, следовательно, функция типобезопасным.

С классами BaseBad и DerivedBad эти два метода имеют одинаковое стирание: void doStuff(List list); однако система типа не может безопасно конвертировать из List<Integer> в List<Double> (или в любой момент от List). Разрешение этого преобразования потенциально может привести к потере Double s в списки Integer s (или проблема, связанная с генериками для обнаружения времени компиляции).

Наличие методов переопределения дружественных после стирания не означает, что система типов не может проверить на наличие несовместимости перед стиранием.

РЕДАКТИРОВАТЬ

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

См: Java generics - type erasure - when and what happens

Существует и другой случай, когда вы передаете общий класс типа стертых в переопределение и потому, что тип система не может проверить, прошли ли вы правильный список, основанный на типе методы , он должен это позволить.