Objects.compare（）方法的目的是什么？

Question

Java 7引入了包含“ null -safe或null -tolerant”方法的Objects类，包括compare(T, T, Comparator<T>) 。 但我什么时候会用

Objects.compare(left, right, comparator);

简单地打电话

comparator.compare(left, right);

？

Objects.compare只有null -safe如果comparator也是如此，为什么我要包装compare-call？ 首先检查对象标识的优化似乎应该在比较器本身中完成。 我能看到的行为唯一真正的区别是comparator.compare(left, right)如果所有comparator ， left和right都为null ，则抛出NullPointerException ，而Objects.compare则不是; 这似乎并不是一个重要的考虑因素，可以保证新的标准库方法。

我错过了一些明显的东西吗？

Answer 1

这很有意思。 Objects类以及这个.compare()方法由Joe Darcy在3b45b809d8ff中引入，提交消息引用了Bug 6797535，并指出“Sherman”（ Xueming Shen？）已经签名。 除了这个bug之外，还有一个来自2009年9月的线程讨论了要添加到Objects 。 在线程中讨论添加compare(int, int) （和类似）原始比较方法，并最终决定它们应该驻留在它们各自的包装类中（参见Integer.compare() ）。 这个方法稍后在该线程中介绍，但没有任何我能找到的评论。

稍后会发送一个包含Objects.compare() 的补丁进行审核 ， Joshua Bloch回复 ：

我认为你不应该添加这种方法（比较（T a，T b，Comparator c））。 它的实用性尚不清楚，并且它没有本课程中其他方法的功率重量比。

达西回应 ：

是的，我把它包含在EJv2中的“第12项：考虑实施可比较”中。

我不清楚这个方法对第12项有什么看法，但问题似乎没有再次提出。 我推断，出于风格原因，我的目的是提供一个等同于原始compare()的方法，但我没有找到实际上是原因的证据。

---

值得注意的是，在Darcy和Bloch之间的相同交换中， Objects.toString()方法同样受到Bloch的批评：

我肯定/不会/添加此方法（Objects.toString）。 它没有带来任何尚未存在的表格。 人们知道并使用String.valueOf。 让我们不要通过添加另一种选择来混淆水域。

但是，正如我们所知，它没有被删除，达西只是回应：

如此指出。

---

总而言之，在我看来，这是在没有太多意图的情况下引入的。 它被提出并且所提出的反对意见并没有阻止它被检查。我想像一个更严格的设计审查会在离开它时犯错误，就像Bloch建议的那样。

您可能也对这个类似的问题感兴趣（虽然它是关于实现细节，而不是API更改）： 为什么Arrays.fill（）不再用于HashMap.clear（）？