Использование параметра типа в справочнике по методам Java

Я полагал, что вывод типа локальной переменной Java 10 (var name = ...;) будет ответом на эту загадку. Вместо того, чтобы тип переменной назначения предоставлял тип для ссылки на метод, в правой части необходимо было бы полностью указать тип, что потребовало бы параметра типа (::<T>) в ссылке на метод.

Сначала придумали ворота...

var arraySorter = Arrays::<Double>sort;

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

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

class Spy {
    static <T> Function<T,T> f2(Function<T,T> f) {
        return f.andThen(f);
    }

    static <T> T identity(T t) {
        return t;
    }
}

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

Function<Double,Double> double_identity = f2(Spy::<Double>identity);

Как и ожидалось, мы можем удалить ::<Double>

Function<Double,Double> double_identity = f2(Spy::identity);

Неожиданно, с выводом типа локальной переменной все в порядке.

var double_identity = f2(Spy::identity);             // Infers <Object>!
Object obj = null;
double_identity.apply(obj); 

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

var double_identity = f2(Spy::<Double>identity);     // Error: Double != Object

Немного поругавшись, я понял, почему. Мы должны применить тип к самому методу f2:

var double_identity = Spy.<Double>f2(Spy::identity); // Works.

Оглядываясь назад, это имеет некоторый смысл. Тип переменной обычно обеспечивает контекст для внешней функции. Присвоение результата переменной Function<Double,Double> позволяет компилятору определить тип f2(...), который затем передает этот тип в аргументы. С var name = ... без явного типа доступен только тип Object, поэтому компилятор выводит Spy.<Object>f2(...), а затем определяет, что тип аргумента должен быть Function<Object,Object>.

К сожалению, кажется, что он не анализирует изнутри, так что Spy::<Double>identity не приводит к тому, что функция выводится как Spy.<Double>f2(...), а переменная - как Function<Double,Double>. Может Ява 11? Возможно, он слишком сильно сломается и не сможет работать.

Однако это положило конец моим попыткам злоупотребить var name = ...;, чтобы решить загадку ОП.

Большое спасибо @Eugene за критику моих предыдущих попыток до выпуска Java 10.

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

Тем не менее, есть определенные обстоятельства, в которых вам необходимо вручную предоставить подсказки типа.

В любом случае, Java 8 улучшает вывод общих аргументов.

Итак, делаем следующее:

BiConsumer<Double[], Comparator<Double>> arraySorter = Arrays::sort;

в полностью допустимом из-за вывода типа.

Пара примеров, которые я могу придумать прямо сейчас, которые не работали бы в Java-7, но работают в Java-8, выглядят примерно так:

void exampleMethod(List<Person> people) {
      // do logic
} 

exampleMethod(Collections.emptyList())

Другой пример:

someMethodName(new HashMap<>());
...
void someMethodName(Map<String, String> values);

Ранее от вас требовалось явно указать аргументы типа.

Кроме того, из-за вышеупомянутого вывода типа это точная причина, по которой мы теперь можем сделать что-то вроде:

...
...
.collect(Collectors.toList());

вместо этого парня:

...
...
.collect(Collectors.<Person>toList());

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

Java 8 реализует обобщенный вывод целевого типа (JEP 101), который позволяет компилятору определять < em>параметр типа универсального метода. В вашем примере компилятор Java 8 выводит параметр типа метода sort из правой части присваивания.

JEP 101 также предлагал общий вывод целевого типа для связанных вызовов методов, но он не был реализован, потому что сложности, которую он внес бы в алгоритм вывода (обсуждается здесь и здесь). Таким образом, связанные вызовы универсального метода являются примером, в котором параметр типа универсального метода не может быть выведен.

Рассмотрим следующий фрагмент кода:

class Main {

    String s = MyList.nil().head(); // Incompatible types. Required: String. Found: Object.

    static class MyList<E> {
        private E head;
        static <Z> MyList<Z> nil() { return new MyList(); }
        E head() { return head; }
    }
}

Компилятору не удается вывести параметр типа для универсального метода nil() в String s = MyList.nil().head(). Итак, мы должны предоставить больше информации алгоритму вывода, либо добавив параметр типа

String s = MyList.<String>nil().head();

или путем разделения связанных вызовов

MyList<String> ls = MyList.nil();
String s = ls.head();

Примечание. Пример цепных вызовов не содержит ссылки на общий метод (синтаксис ::<>), как в исходном вопросе, но метод вывода, используемый в обоих примерах, одинаков. Следовательно, ограничения вывода также одинаковы.