使用Collections.sort后在List中添加了新的排序方法

Question

使用Collections.sort后在List中添加了新的排序方法

shu*_*ana 17 java collections list java-8

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

Answer 1

JB *_*zet 28

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

覆盖方法可能不仅更快,而且可以强制执行额外的保证.例如,在Java 8之前,如果没有额外的手动同步,将`Collections.sort`应用于`synchronizeList`或`Vector`是不安全的.今天,它委托给`List.sort`并且这些集合用`synchronized`方法覆盖它...此外,不可修改的列表可以无条件地抛出`UnsupportedOperationException`,即使`sort`尝试不会导致实际的更改. (8认同)
@Eugene对`SortedSet`检查`List`没有任何意义; 在一个类中正确实现这两个合同是不可能的.此外,我怀疑是否有人正在明确检查排序是否改变了什么,只是隐式发生,例如`Collections.sort(Collections.<String> emptyList())`不会失败,同样`Collections.emptyList().addAll (Collections.emptyList())`什么都不做.也许,这是为了保持兼容性.较新的构造,例如`Collections.sort(List.<String> of())`或`List.of().addAll(List.of());`做惯用的无条件抛出. (2认同)
@Holger是的,保留零元素到空(和不可修改)列表的旧行为以保持兼容性.这允许应用程序中的潜在错误,因为这"工作"直到有人试图添加非零数量的元素,此时它会爆炸.较新的实现提供了更"快速失败"的行为.正如您所观察到的,新的`sort`默认方法也可以提供快速失败的行为.旧的`Collections.sort`算法,如果在不可修改的列表上调用,将复制出来,进行排序,然后在复制回原始列表时**然后**爆炸. (2认同)
@StuartMarks这是我可以忍受的权衡.毕竟,破坏的比较器无论如何都会破坏列表,例如,如果没有抛出异常,这更有可能在引入TimSort之前,所以与旧的行为相比,我们不会松动太多(取决于我们挖掘的深度) ."失败的幂等"是一个很好的但不应该牺牲大量正确代码的性能. (2认同)

Answer 2

Hul*_*ulk 15

JB Nizet的答案已经为您提供了添加此方法的理由.第二个方面是:

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

无论是List接口和静态工具Collections都在同一个版本1.2中添加,所以它本来可能从一开始就包含它.

在错过了这个机会之后,再也无法添加它了.向接口添加方法是一种default在Java 1.8中引入-methods 之前会破坏向后兼容性的更改.

归档时间：	7 年，5 月前
查看次数：	1309 次
最近记录：	7 年，5 月前