Очень смущает вывод типа компаратора Java 8

Я изучал разницу между Collections.sortи list.sort, особенно в отношении использования Comparatorстатических методов и того, требуются ли типы параметров в лямбда-выражениях. Прежде чем мы начнем, я знаю, что могу использовать ссылки на методы, например, Song::getTitleдля решения моих проблем, но мой запрос здесь - это не столько то, что я хочу исправить, а то, на что я хочу получить ответ, т.е. почему компилятор Java обрабатывает это таким образом .

Это моя находка. Предположим, у нас есть ArrayListтип Song, с добавленными песнями, есть 3 стандартных метода получения:

    ArrayList<Song> playlist1 = new ArrayList<Song>();

    //add some new Song objects
    playlist.addSong( new Song("Only Girl (In The World)", 235, "Rhianna") );
    playlist.addSong( new Song("Thinking of Me", 206, "Olly Murs") );
    playlist.addSong( new Song("Raise Your Glass", 202,"P!nk") );

Вот вызов обоих типов методов сортировки, которые работают без проблем:

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

playlist1.sort(
            Comparator.comparing(p1 -> p1.getTitle()));

Как только я начинаю цепочку thenComparing, происходит следующее:

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

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

т.е. синтаксические ошибки, потому что он больше не знает тип p1. Чтобы исправить это, я добавляю тип Songк первому параметру (сравнения):

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

playlist1.sort(
        Comparator.comparing((Song p1) -> p1.getTitle())
        .thenComparing(p1 -> p1.getDuration())
        .thenComparing(p1 -> p1.getArtist())
        );

А теперь - ЗАДАЧА. Для p laylist1.sort, то есть для списка, это решит все ошибки компиляции для обоих следующих thenComparingвызовов. Однако Collections.sortон решает его для первого, а не для последнего. Я тестировал добавление нескольких дополнительных вызовов, thenComparingи он всегда показывает ошибку для последнего, если я не поставил (Song p1)параметр.

Теперь я продолжил тестировать это, создав TreeSetи используя Objects.compare:

int x = Objects.compare(t1, t2, 
                Comparator.comparing((Song p1) -> p1.getTitle())
                .thenComparing(p1 -> p1.getDuration())
                .thenComparing(p1 -> p1.getArtist())
                );


    Set<Song> set = new TreeSet<Song>(
            Comparator.comparing((Song p1) -> p1.getTitle())
            .thenComparing(p1 -> p1.getDuration())
            .thenComparing(p1 -> p1.getArtist())
            );

То же самое, что и для TreeSet, нет ошибок компиляции, кроме Objects.compareпоследнего вызоваthenComparing показывает ошибку.

Может ли кто-нибудь объяснить, почему это происходит, а также почему нет необходимости использовать (Song p1) при простом вызове метода сравнения (без дальнейших thenComparingвызовов).

Еще один вопрос по той же теме - когда я делаю это с TreeSet:

Set<Song> set = new TreeSet<Song>(
            Comparator.comparing(p1 -> p1.getTitle())
            .thenComparing(p1 -> p1.getDuration())
            .thenComparing(p1 -> p1.getArtist())
            );

т.е. удалите тип Songиз первого лямбда-параметра для вызова метода сравнения, он показывает синтаксические ошибки при вызове сравнения и первом вызове, thenComparingно не последнем вызове thenComparing- почти полная противоположность тому, что происходило выше! Принимая во внимание, что для всех остальных трех примеров, то есть с Objects.compare, List.sortи Collections.sortкогда я удаляю это первымSong тип паров он показывает ошибки синтаксиса для всех вызовов.

Спасибо заранее.

Отредактировано, чтобы включить снимок экрана с ошибками, которые я получал в Eclipse Kepler SR2, которые, как я обнаружил, специфичны для Eclipse, потому что при компиляции с использованием java-компилятора JDK8 в командной строке он компилируется нормально.

Во-первых, все примеры, которые вы называете причиной ошибок, отлично компилируются с эталонной реализацией (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>.

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

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

1. Используйте новый синтаксис ссылки на метод Java 8

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

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

     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)
               );
   

   РЕДАКТИРОВАТЬ

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

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

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

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

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

Явно укажите переменную вашей первой функции сравнения, и тогда все готово. У меня есть отсортированный список объекта 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());

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

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

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