Блог

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

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

     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 из первого лямбда-параметра для вызова метода сравнения, он показывает синтаксические ошибки при вызове comparing и первом вызове thenComparing , но не при последнем вызове thenComparing — почти противоположно тому, что происходило выше! Принимая во внимание, что для всех остальных 3 примеров, т.Е. С 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() , что он должен возвращать a 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> .

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

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

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 , что синтаксическая ошибка «last» вводит вас в заблуждение. На самом деле это проблема типа со всей цепочкой, просто компилятор помечает конец цепочки как синтаксическую ошибку, потому что, я думаю, именно тогда конечный возвращаемый тип не совпадает.

Я не уверен, почему 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(...) создает границу песни для переменной типа E из объявления playlist1, которая «передается» в компаратор.

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

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