问题描述
java.util.stream.Stream
interface has two versions of sorted
method – sorted()
which sorts elements in natural order and sorted(Comparator)
. Why min()
method was not introduced to Stream
interface, which would return minimal element from natural-ordering point of view?
It should be clear that for min
, max
, and sorted
, adding a method to Stream
that does not require a comparator introduces a way to lose the generic type safety. The reason is that the current version of the Java language does not support restricting methods to instances of a specific parameterization, i.e. limit them to streams of comparable elements.
So the question could be the other way round, why has this potential break of the type safety been allowed with sorted()
?
I can’t look into the developers mind, but one interesting point is that sorting has been treated specially for a long time now. With the introduction of Generics, it became possible to enforce that sorting without a Comparator
can only be attempted for collections or arrays with comparable elements. However, especially when implementing generic collections, developers might face the fact that arrays can’t be created with a generic element type. There might be other scenarios, where a developer encounters an array or collection of a formally non-comparable type while the contained elements are comparable for sure. As said, I can’t look into the developers mind to say, which scenarios were considered.
But
Arrays.sort(Object[])
does not enforce the array type to be a subtype ofComparable
. Even if it did,sort(T[] a, Comparator<? super T> c)
specifies that anull
comparator implies "natural order", which allows requesting natural order for any typeCollections.sort(List<T> list)
requires a comparable element type, butCollections.sort(List<T> list, Comparator<? super T> c)
again specifies that anull
comparator implies "natural order", so there’s still an easy way to undermine the type system. Since the "null
means natural" rule was already specified before Generics existed, it had to be kept for compatibility.
But it’s not just all about backwards compatibility. List.sort(Comparator)
, introduced in Java 8, is also specified as accepting null
as argument for "natural order", so now we have another scenario, where an implementer might have to sort data without a compile-time type that guarantees comparable elements.
So when it comes to sorting, there are already lots of opportunities to dodge the type system. But Stream.sorted(Comparator)
is the only sort method not accepting a null
comparator. So sorting by natural order without specifying Comparator.naturalOrder()
is only possible using sorted()
without arguments. By the way, having an already sorted input with a null
comparator and requesting sorted()
without comparator is the only situation where the Stream implementation will detect that sorting isn’t necessary, i.e. it doesn’t compare comparators and doesn’t check for Comparator.naturalOrder()
.
Generally, the type safety of comparators is astonishing weak. E.g. Collections.reverseOrder()
returns a comparator of arbitrary type, not demanding the type to be comparable. So instead of min()
, you could use max(Collections.reverseOrder())
to request the minimum, regardless of the stream’s formal type. Or use Collections.reverseOrder(Collections.reverseOrder())
to get the equivalent of Comparator.naturalOrder()
for an arbitrary type. Likewise, Collator
implements Comparator<Object>
, for whatever reason, despite it can only compare String
s.
这篇关于为什么 Java 8 Stream 接口没有 min() 无参数版本?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!