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

Question

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

Objects.compare(left, right, comparator); 

над простым вызовом

comparator.compare(left, right); 

?

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

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

Answer 1

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

Позже a patch is sent out for review, содержащие Objects.compare() и Joshua Bloch replies:

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

Darcy responds:

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

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

---

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

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

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

Так отмечено.

---

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

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