Jaki jest cel metody Objects.compare()?

Question

Java 7 wprowadziła klasę Objects zawierającą "tolerowane" lub null "metody, w tym compare(T, T, Comparator<T>). Ale kiedy będę kiedykolwiek używać

Objects.compare(left, right, comparator); 

nad prostu dzwoniąc

comparator.compare(left, right); 

?

Objects.compare jest tylko null -safe, jeśli jest również comparator, więc dlaczego miałbym zawijać połączenie porównania? Optymalizacja pierwszego sprawdzania tożsamości obiektu wydaje się być czymś, co należy zrobić w samym komparatorze. A jedyną istotną różnicą w zachowaniu, jakie widzę, jest to, że comparator.compare(left, right) wyrzuca NullPointerException, jeżeli wszystkie z nich są comparator,i nie są w stanie; tak naprawdę nie wydaje się to wystarczająco ważną kwestią, aby uzasadnić nową standardową metodę biblioteki.

Czy brakuje tu czegoś oczywistego?

Answer 1

To było interesujące do kopania. Klasa Objects, wraz z tą metodą .compare(), została wprowadzona w 3b45b809d8ff przez Joe Darcy, a wiadomość o zatwierdzeniu przytacza Bug 6797535 i oznacza, że ​​"Sherman" (Xueming Shen?) Jest na niej podpisany. Oprócz błędu jest this thread z września 2009, omawiając funkcje, które należy dodać do Objects. W wątku ludzie opowiadają o dodawaniu prymitywnych metod porównywania compare(int, int) (i tym podobnych) i ostatecznie decydują, że powinny one znajdować się w odpowiednich klasach (patrz Integer.compare()). Ta metoda została wprowadzona later in that thread, ale bez komentarza, który mogę znaleźć.

Później a patch is sent out for review zawierający Objects.compare() i Joshua Bloch replies:

Nie sądzę, należy dodać tę metodę (Porównaj (T a T b, Komparator c)). Jego użyteczność jest niejasna i nie ma stosunku mocy do masy innych metod w tej klasie.

Darcy responds:

Tak, to zawarte z "Punkt 12: Należy rozważyć wdrożenie Porównywalne" z EJv2 w umyśle.

To nie jest dla mnie jasne, co ta metoda przynosi do stołu dotyczącego Item 12, ale problem wydaje się nie zostały ponownie podniesione. Wnioskuję, że celem było dostarczenie metody równoważnej prymitywnej compare() ze względów stylistycznych, ale nie znalazłem dowodów, które były w rzeczywistości przyczyną.

---

Warto zauważyć, że w tym samym wymiany między Darcy i Blocha zastosowano metodę Objects.toString() jest podobnie krytykowany przez Blocha:

Zdecydowanie/nie/dodać tę metodę (Objects.toString).Nie przynosi nic do stołu, którego jeszcze tam nie ma. Ludzie znają i używają String.valueOf. Nie mącmy wody, dodając kolejny wybór.

Ale jak wiemy, że nie został usunięty, Darcy po prostu odpowiedziała:

więc zauważyć.

---

Więc podsumowując, wydaje mi się, jak to zostało wprowadzone bez większego intencji. Zostało to zaproponowane, a zgłoszone zastrzeżenia nie blokowały jego sprawdzania. Wyobrażam sobie, że bardziej rygorystyczna ocena projektu byłaby błędna po stronie pozostawienia go, jak sugerował Bloch.

Możesz być również zainteresowany tym podobnych kwestii (choć to około szczegółów wdrażania, a nie zmiana API): Why is Arrays.fill() not used in HashMap.clear() anymore?