使用 Collections.sort 后在 List 中添加了新的排序方法 [重复]答案

【问题标题】：New sort method added in List after using Collections.sort [duplicate]使用 Collections.sort 后在 List 中添加了新的排序方法 [重复]
【发布时间】：2018-09-14 19:49:47
【问题描述】：

当我们有使用Collections.sort对列表进行排序的规定时，为什么在java 8的java.util.List中添加了新的排序方法

【问题讨论】：

你的问题和你的解释一样，请改进你的解释。
@AbhishekEkaanth 你到底想要什么？ OP 无法就理论问题给你解释。
@Shuchita 检查这个问题答案stackoverflow.com/questions/34910841/…
@Kailas 感谢您提供此链接

标签： java list collections java-8

【解决方案1】：

因为它使 API 更加直观和面向对象
因为它允许 List 的实现使用更快的排序算法，最适合其内部结构。例如，ArrayList 可以对其内部数组进行排序，而无需像默认实现那样首先进行复制。

【讨论】：

覆盖方法不仅速度更快，而且可能会强制执行额外的保证。例如。在 Java 8 之前，如果没有额外的手动同步，将 Collections.sort 应用于 synchronizeList 或 Vector 是不安全的。今天，它委托给List.sort，这些集合用synchronized 方法覆盖它……此外，不可修改的列表可以无条件地抛出UnsupportedOperationException，即使sort 尝试不会导致实际更改。
@Holger 我知道第二个，有趣的是我发现它是正确的（我知道我在这里自找麻烦），但我的直觉是，而不是潜在地排序并检查排序是否有是否改变了任何东西，简单地抛出异常更惯用；除非例如对SortedSet 进行检查...
@Eugene 检查List 和SortedSet 没有任何意义；不可能在一个类中正确地实现两个契约。此外，我怀疑是否有人正在明确检查排序是否改变了任何东西，这只是隐式发生的，例如Collections.sort(Collections.<String>emptyList()) 不会失败，同样Collections.emptyList().addAll(Collections.emptyList()) 什么也不做。也许，这是为了兼容性而保留的。较新的结构，例如Collections.sort(List.<String>of()) 或 List.of().addAll(List.of()); 做惯用的无条件投掷。
@Holger 是的，为了兼容性，保留零元素到空（且不可修改）列表的旧行为。这允许应用程序中存在潜在错误，因为这“有效”直到有人尝试添加非零数量的元素，此时它会爆炸。较新的实现提供了更“快速失败”的行为。正如您所观察到的，新的sort 默认方法还可以提供快速失败的行为。旧的Collections.sort 算法，如果在不可修改的列表上调用，会复制出来，进行排序，然后然后在复制回原始列表时崩溃。
@StuartMarks 这是我可以接受的权衡。毕竟，损坏的比较器无论如何都会破坏列表，例如如果没有抛出异常，这在引入 TimSort 之前更有可能发生，因此与旧行为相比，我们不会丢失太多（取决于我们挖掘的深度）。 “故障幂等”是一项不错的选择，但不应大量牺牲正确代码的性能。

【解决方案2】：

JB Nizet's answer 已经说明了为什么添加此方法是个好主意。第二个方面是：

如果添加这个方法显然是个好主意，为什么在一些早期版本中没有添加它？

List 接口和静态实用程序Collections 都是在同一个版本 1.2 中添加的，因此可以从一开始就包含它。

在错过了那个机会之后，就没有办法再添加它了。在 Java 1.8 中引入 default-methods 之前，将方法添加到接口是一项会破坏向后兼容性的更改。

【讨论】：

很好，就像在另一个问题上发现错误 199 一样好 ;-)