chabapokДиезConsumer - контравариантный тип, и требует использования супертипа, а не потомка.
Такого понятия не существует в java.
В какую сторону требуется наследование - определяется словом super или extends.
Да, в Java нет явного указания, что параметр типа является ко- или контравариантным (как в Scala или c#).
Но вариантность в широком смысле - это поведение типа, а не фича языка
https://ru.wikipedia.org/wiki/Ковариантность_и_контравариантность_(программирование)#Java
chabapokК вашему примеру я приходил методом тыка. Это немножко не то, по той причине, что такой способ позволяет идти по ветке наследования вверх. Это относительно бесполезная фишка для Consumer-ов, она предназначена для контейнеров. В Consumer можно писать без super. Следующий пример компилится:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
class Bar {
void myFunc(){ }
}
class Bar1 extends Bar{
void myFunc(){ }
void myFunc1(){ }
}
Consumer<? super Bar1> f2 = Bar1::myFunc;
f2 = Bar1::myFunc1;
f2 = Bar::myFunc;
f2 = Object::notify;
//теперь то же без super
Consumer<Bar1> f3 = Bar1::myFunc1;
Consumer<Bar1> f4 = Bar1::myFunc;
f2 = Bar::myFunc;
f2 = Object::notify;
В контейнерах все хитрей, есть урок на русском по этой теме тут
...
Так что логично было бы предположить, что extends позволить идти по ветке наследования вниз. Но нет, со ссылками на метод это не работает.
Принципиальной разницы между контейнерами и функциональными интерфейсами я не вижу - поведение generic-типов одинаковое.
К Consumer<T> есть парный интерфейс Supplier<T> - он-то как раз позволяет использовать подклассы для параметризации:
1.
2.
3.
4.
5.
6.
7.
8.
Supplier<? extends Bar> s1 = new Supplier<Bar1>() {
@Override
public Bar1 get() {
return new Bar1();
}
};
Bar res = s1.get(); // всё ОК
Рассматривайте Supplier как IN-коллекцию, а Consumer - как OUT-коллекцию.
1.
2.
3.
4.
5.
void copy(Supplier<? extends Bar> src, // IN-param, extends
Consumer<? super Bar> dest) { // OUT-param, super
dest.accept(src.get());
}
Всё как в уроке :)
