Прошу администрацию разъяснить

Вот такой проходит

@Override
   public int compareTo(MoveEfficiency o) {
       int result = Integer.compare(numberOfEmptyTiles, o.numberOfEmptyTiles);
       if (result != 0) return result;

       return Integer.compare(score,o.score);
   }

Вот такой не проходит

@Override
    public int compareTo(Object o) {
        MoveEfficiency me = (MoveEfficiency) o;

        int result = numberOfEmptyTiles - me.numberOfEmptyTiles;
        if (result != 0) return result;

        return score - me.score;
    }

И вот такой не проходит

@Override
   public int compareTo(MoveEfficiency o) {
       int result = numberOfEmptyTiles - o.numberOfEmptyTiles;
       if (result != 0) return result;

       return score - o.score;
   }

да и правда странно, но есть ещё одно отличие это параметр метода.

С другим параметром тоже, не проходит. Значит такова воля валидатора. А то я думал, может здесь сокрыт какой-то принципиальный момент, типа скорости или еще чего-то. Благодарю за ответ.

реализовывать compareTo через вычитание - плохой тон. в нашей задаче так прошло бы. но в общем случае может возникнуть баг. в свою очередь Integer.compare - всегда корректно сравнивает любые значения Integer.

Виталий, благодарю за информацию. Не помню, чтобы в уроках на этом акцентировали внимание.

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

2 вариант это когда у тебя имплементируется от Comparable<> а 3 вариант это когда уже типизируеш Comparable<MoveEfficiency> тогда и аргументы метода compareTo будут отличатся

Спасибо за ваш вопрос - благодаря этому рассуждению сразу поняла, почему валидатор не принимает - ато еще долго бы думала - что там в логике неверно, а оказывается не в логике )