Странности Generic типов Java

Автор: admin от 31-05-2017, 23:05, посмотрело: 158

Я множество раз слышал о том, что дизайн Generic типов в Java является неудачным. По большей части претензии сводятся к отсутствию поддержки примитивных типов (которую планируют добавить) и к стиранию типов, а конкретнее — невозможности получить фактический тип параметра в рантайме. Лично я не считаю стирание типов проблемой, как и дизайн Generic-ов плохим. Но есть моменты, которые меня порядком раздражают, но при этом не так часто упоминаются.


1


Например, мы знаем, что метод Class#getAnnotation параметризован и имеет следующую сигнатуру: public A getAnnotation(Class annotationClass). Значит, можно писать вот такой код:


Deprecated d = Object.class.getAnnotation(Deprecated.class);

Тут я решаю вынести Object.class в отдельную переменную и код перестаёт компилироваться:


Class clazz = Object.class;
// incompatible types:
// java.lang.annotation.Annotation cannot be converted to java.lang.Deprecated
Deprecated d = clazz.getAnnotation(Deprecated.class);

Где я ошибся?


Ошибся я в том, что не параметризовал тип переменной clazz.
Получается, что стирание у типа Class так же стирает типы во всех его методах! Зачем так было делать — понятия не имею. Вносим минимальное исправление в код и всё работает как надо.


Class<Object> clazz = Object.class;
Deprecated d = clazz.getAnnotation(Deprecated.class);

2


Второй пример немного надуманный, но показательный. Представьте, есть у вас такой простой класс:


class Ref<T> {
    private T value = null;

    public T getValue() {
        return value;
    }

    public void setValue(T value) {
        this.value = value;
    }
}

Имея переменную ref я решу написать такой код. Что с ним может произойти плохого?


ref.setValue(ref.getValue());

Разумно было бы считать, что он всегда скомпилируется, но это не так! Вам всего лишь стоит объявить переменную ref с типом Ref и вы получите ошибку incompatible types: java.lang.Object cannot be converted to capture#1 of ?
То есть wildcard в геттере автоматически раскрывается в Object. Мы не можем полагаться на то, что в наших выражениях он будет равен самому себе. Выстрелить себе в ногу этим пусть и сложно, но точно можно.


3


Далее, пусть есть такая очень простая иерархия классов:


class HasList<T extends List> {
    protected final T list;

    public HasList(T list) {
        this.list = list;
    }

    public T getList() {
        return list;
    }
}

class HasArrayList<T extends ArrayList> extends HasList<T> {
    public HasArrayList(T list) {
        super(list);
    }
}

Напишем следующий код:


HasArrayList<?> h = new HasArrayList<>(new ArrayList<>());
ArrayList list = h.getList();

Параметр T класса HasArrayList имеет верхнюю границу равную ArrayList, а значит при стирании типов код всё ещё должен компилироваться.


HasArrayList h = new HasArrayList<>(new ArrayList<>());
// incompatible types: java.util.List cannot be converted to java.util.ArrayList
ArrayList list = h.getList();

Ну вот, опять не работает. Сейчас то что не так?


Не так то, что в сигнатуре метода getList возвращаемым типом является List, а компилятору просто лень расставлять явные приведения типов. Исправляется всё очень просто — надо переопределить данный метод в подклассе.


class HasArrayList<T extends ArrayList> extends HasList<T> {
    public HasArrayList(T list) {
        super(list);
    }

    @Override
    public T getList() {
        return super.getList();
    }
}

При этом компилятор сгенерирует синтетический bridge метод, возвращающий ArrayList, и именно он и будет вызван. Очевидно же...


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


4


Последняя ситуация наиболее хитрая. Решил я написать подобный класс:


class MyArrayList<T extends Cloneable & BooleanSupplier> extends ArrayList<T> {
    public void removeTrueElements() {
        this.removeIf(BooleanSupplier::getAsBoolean);
    }
}

Как вы считаете, будут ли при вызове этого метода какие-нибудь проблемы?


new MyArrayList<>().removeTrueElements();

Может показаться смешным, но этот код при запуске выбросит исключение:


Exception in thread "main" java.lang.BootstrapMethodError: call site initialization exception
...
Caused by: java.lang.invoke.LambdaConversionException: Invalid receiver type interface java.lang.Cloneable; not a subtype of implementation type interface java.util.function.BooleanSupplier
...

Хотя нет, я вас обманул. Этот код будет работать, если компилировать его из JDK9, а вот компилятор JDK8 допускает на нём ошибку.


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


Как исправить код без перехода на Java 9? Вот так:


public void removeTrueElements() {
    this.removeIf(t -> t.getAsBoolean());
}

Ну и откомментировать, конечно, чтобы ваш коллега не сконвертировал всё обратно в method reference.


Вместо заключения


Уверен, у многих из вас тоже встречались ситуации, когда поведение дженериков вызывало недоумение.
Делитесь в комментариях, обсудим.



Источник: Хабрахабр

Категория: Программирование

Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

Добавление комментария

Имя:*
E-Mail:
Комментарий:
Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
Введите два слова, показанных на изображении: *