Очень запутано в выводе типа Java 8 Comparator

Ответ 1

Во-первых, все примеры, которые вы говорите, приводят к ошибкам, компилируются с помощью эталонной реализации (javac от JDK 8.) Они также отлично работают в IntelliJ, поэтому вполне возможно, что ошибки, которые вы видите, являются специфичными для Eclipse.

Ваш основной вопрос, кажется, "почему он перестает работать, когда я начинаю цепочку". Причина в том, что лямбда-выражения и общие вызовы методов - это поли-выражения (их тип чувствителен к контексту), когда они появляются как параметры метода, когда они появляются в качестве выражений приемника метода, они не являются.

Когда вы говорите

Collections.sort(playlist1, comparing(p1 -> p1.getTitle()));

существует достаточная информация о типе для решения как аргумента типа comparing(), так и типа аргумента p1. Вызов comparing() получает свой целевой тип из сигнатуры Collections.sort, поэтому известно, что comparing() должен возвращать Comparator<Song>, и поэтому p1 должен быть Song.

Но когда вы начинаете цепочку:

Collections.sort(playlist1,
                 comparing(p1 -> p1.getTitle())
                     .thenComparing(p1 -> p1.getDuration())
                     .thenComparing(p1 -> p1.getArtist()));

теперь у нас есть проблема. Мы знаем, что составное выражение comparing(...).thenComparing(...) имеет целевой тип Comparator<Song>, но поскольку выражение получателя для цепочки comparing(p -> p.getTitle()) является общим вызовом метода, и мы не можем вывести его параметры типа из других его аргументов, нам не повезло. Поскольку мы не знаем тип этого выражения, мы не знаем, что он имеет метод thenComparing и т.д.

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

• Используйте ссылку на точный метод (один без перегрузок), например Song::getTitle. Затем это дает достаточную информацию о типе, чтобы вывести переменные типа для вызова comparing() и, следовательно, дать ему тип и, следовательно, продолжить цепочку.
• Используйте явный лямбда (как и в вашем примере).
• Предоставьте тип свидетеля для вызова comparing(): Comparator.<Song, String>comparing(...).
• Укажите явный тип цели с помощью литья, выставив выражение получателя в Comparator<Song>.

Ответ 2

Проблема заключается в вызове типа. Не добавляя (Song s) к первому сравнению, comparator.comparing не знает тип ввода, поэтому по умолчанию он имеет значение Object.

Вы можете решить эту проблему 1 из 3 способов:

• Используйте новый синтаксис ссылок на Java 8

   Collections.sort(playlist,
              Comparator.comparing(Song::getTitle)
              .thenComparing(Song::getDuration)
              .thenComparing(Song::getArtist)
              );
  

• Вытащите каждый шаг сравнения в локальную ссылку

    Comparator<Song> byName = (s1, s2) -> s1.getArtist().compareTo(s2.getArtist());
  
    Comparator<Song> byDuration = (s1, s2) -> Integer.compare(s1.getDuration(), s2.getDuration());
  
      Collections.sort(playlist,
              byName
              .thenComparing(byDuration)
              );
  

  ИЗМЕНИТЬ

• Задание типа, возвращаемого компаратором (обратите внимание, что вам нужен как тип ввода, так и тип ключа сравнения)

  sort(
    Comparator.<Song, String>comparing((s) -> s.getTitle())
              .thenComparing(p1 -> p1.getDuration())
              .thenComparing(p1 -> p1.getArtist())
              );
  

Я думаю, что синтаксическая ошибка "last" thenComparing вводит вас в заблуждение. Это на самом деле проблема типа со всей цепочкой, просто компилятор только отмечает конец цепочки как синтаксическую ошибку, потому что это, когда окончательный тип возвращаемого значения не совпадает, я думаю.

Я не уверен, почему List выполняет лучшую работу по определению, чем Collection, поскольку он должен делать один и тот же тип захвата, но, по-видимому, нет.

Ответ 3

playlist1.sort(...) создает привязку Песни для переменной типа E из объявления списка воспроизведения1, который "рябит" к компаратору.

В Collections.sort(...) такой привязки нет, и вывод из типа первого компаратора недостаточен для того, чтобы компилятор вывел остальное.

Я думаю, что вы получите "правильное" поведение от Collections.<Song>sort(...), но не имеете установки java 8, чтобы проверить его для вас.

Ответ 4

Другой способ справиться с этой ошибкой времени компиляции:

Вставьте свою первую переменную функции сравнения в явном виде, а затем хорошо перейти. У меня есть список объектов org.bson.Documents. Посмотрите пример кода

Comparator<Document> comparator = Comparator.comparing((Document hist) -> (String) hist.get("orderLineStatus"), reverseOrder())
                       .thenComparing(hist -> (Date) hist.get("promisedShipDate"))
                       .thenComparing(hist -> (Date) hist.get("lastShipDate"));
list = list.stream().sorted(comparator).collect(Collectors.toList());