Какова цель метода Objects.compare()?

В Java 7 представлен класс Objects, содержащий методы null -safe или null -tolerant, включая compare(T, T, Comparator<T>). Но когда я когда-нибудь буду использовать

Objects.compare(left, right, comparator);

по простому вызову

comparator.compare(left, right);

?

Objects.compare является только null -safe, если comparator также, так зачем мне обертывать вызов сравнения? Оптимизация первой проверки для идентичности объекта кажется чем-то, что должно быть сделано в самом компараторе. И единственное реальное различие в поведении, которое я вижу, заключается в том, что comparator.compare(left, right) выбрасывает a NullPointerException, если все comparator, left и right являются null, а Objects.compare - нет; это на самом деле не выглядит достаточно важным, чтобы гарантировать новый метод стандартной библиотеки.

Я пропустил что-то очевидное здесь?

Ответы

Ответ 1

Это было интересно разобраться. Класс Objects, наряду с этим методом .compare(), был введен в 3b45b809d8ff Джо Дарси, а сообщение commit цитирует Ошибка 6797535 и указывает, что "Шерман" (Xueming Shen?) подписал контракт с ним. В дополнение к ошибке есть этот поток от сентября 2009 года, обсуждая, какие функции добавить в Objects. В обсуждении темы обсуждается добавление примитивных методов сравнения compare(int, int) (и т.п.) и, в конечном итоге, решение о том, что они должны находиться в соответствующих классах оболочек (см. Integer.compare()). Этот метод вводится позже в этом потоке, но без комментариев, которые я могу найти.

Позже патч отправлен для просмотра, содержащий Objects.compare() и Джошуа Блох отвечает:

Я не думаю, что вы должны добавить этот метод (сравните (T a, T b, Comparator c)). Его полезность неясна, и у нее нет отношение мощности к весу других методов в этом классе.

Дарси отвечает:

Да, я включил это в "Пункт 12: Рассмотрите возможность внедрения Comparable" от EJv2.

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

Следует отметить, что в том же обмене между Дарси и Блохом метод Objects.toString() так же критикован Блохом:

Я бы определенно/не добавлял этот метод (Objects.toString). Это ничего не приносит в таблицу, которая еще не существует. Люди знают и используют String.valueOf. Позвольте не мутить воды, добавив еще один выбор.

Но, как мы знаем, он не был удален, Дарси просто ответил:

Итак, отметим.

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

Вам также может быть интересен этот похожий вопрос (хотя он касается детали реализации, а не изменения API): Почему Arrays.fill() не используется в HashMap.clear( ) больше?