Общие методы Java в классах generics

С Java Generics, если вы используете сырую форму универсального класса, то все дженерики в классе, даже несвязанные общие методы, такие как ваш makeSingletonList и doSomething методы, становятся сырыми. Причина, как я понимаю, заключается в обеспечении обратной совместимости с Java-кодом, написанным pre-generics.

если нет никакой пользы для вашего параметра универсального типа T, потом просто удалите его из MyGenericClass, оставляя ваши методы общими с K. Иначе тебе придется живите с тем, что параметр типа класса T должен быть предоставлен вашему классу для использования дженериков на чем-либо еще в классе.

я нашел одну причину полностью отказаться от дженериков (однако это не совсем хорошо). Причина: дженериков может быть ограничен. Рассмотрим этот класс:

public static class MyGenericClass<T> {
    public <K extends T> K doSomething(K k){
        return k;
    }

    public <K> List<K> makeSingletonList(K k){
        return Collections.singletonList(k);
    }
}

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

makeSingletonList компилируется, потому что Java не снят слепок с List to List<K> (однако компилятор показывает предупреждение).

это не отвечает на фундаментальный вопрос, но решает вопрос о том, почему makeSingletonList(...) компилируется в то время как doSomething(...) нет:

в нетипичной реализации MyGenericClass:

MyGenericClass untyped = new MyGenericClass();
List<String> list = untyped.makeSingletonList("String");

...составляет:

MyGenericClass untyped = new MyGenericClass();
List list = untyped.makeSingletonList("String");
List<String> typedList = list;

это будет компилироваться (с несколькими предупреждениями), но затем откроется для ошибок выполнения.

действительно, это также аналогично:

MyGenericClass untyped = new MyGenericClass();
List<Integer> list = untyped.makeSingletonList("String"); // this compiles!!!
Integer a = list.get(0);

...который компилируется, но будет бросать runtime ClassCastException при попытке и получить String значение и бросить его в Integer.

причиной этого является обратная совместимость с кодом pre-generics. Код pre-generics не использовал универсальные аргументы, вместо этого используя то, что сегодня кажется необработанным типом. Код pre-generics будет использовать Object ссылки вместо ссылок с использованием универсального типа, а необработанные типы используют тип Object для всех общих аргументов, поэтому код действительно был обратно совместим.

в качестве примера, рассмотрим этот код:

List list = new ArrayList();

это pre-generic код, и после введения дженериков это интерпретировалось как необработанный общий тип, эквивалентный:

List<?> list = new ArrayList<>();

потому что ? нет extends или super ключевое слово после него, он преобразуется в это:

List<Object> list = new ArrayList<>();

версия List который использовался до того, как дженерики использовали Object для ссылки на элемент списка, и эта версия также использует Object для ссылки на элемент списка, поэтому обратная совместимость сохраняется.

из моего комментария на MAnyKeys ответ:

Я думаю, что полное стирание типа имеет смысл в сочетании с упомянутой обратной совместимостью. Когда объект создается без аргументов универсального типа может быть (или должен быть?) предположил, что использование объекта происходит в общих кодов.

рассмотрим этот устаревший код:

public class MyGenericClass {
    public Object doSomething(Object k){
        return k;
    }
}

называются так:

MyGenericClass foo = new MyGenricClass();
NotKType notKType = foo.doSomething(new NotKType());

теперь класс и его метод сделаны generic:

public class MyGenericClass<T> {
    public <K extends KType> K doSomething(K k){
        return k;
    }
}

сейчас выше вызывающий код не компилировать как NotKType - это не suptype из KType. Чтобы избежать этого, общие типы заменяются на Object. Хотя есть случаи, когда это не имело бы никакого значения (например, ваш пример), для компилятора, по крайней мере, очень сложно проанализировать, когда. Возможно, даже невозможно.

Я знаю, что этот сенарио кажется немного сконструированным, но я уверен, что это происходит время от времени.