java.util.stream.Streamable 发生了什么?
早期jdk8-ea javadocs 像这样 表示有一个 java.util.stream.Streamable 接口，它与 Stream 的关系似乎与 Iterable 相同必须有一个 Iterator.
Early jdk8-ea javadocs like this indicate there was a java.util.stream.Streamable interface, which would appear to have the same relationship to a Stream as Iterable has to an Iterator.
现在我们似乎被 Supplier 困住了，这肯定是不一样的.
Now it seems like we're stuck with Supplier<Stream>, which is certainly not the same.
Streamable 发生了什么?
推荐答案
前段时间已下架.理由 删除由 Brian Goetz 给出:
It's been removed some time ago. The rationale for the removal was given by Brian Goetz:
目前唯一实现者是 Collection，以及所有其他流承载方法正在提供专门的流(chars()、codePoints()、lines() 等)使用比流"更合适的方法名称.所以我认为我们应该删除 Streamable 并保留 stream()/parallel() 方法集合(或可能将它们向上移动 Iterable).
Currently the only implementor is Collection, and all of the other stream-bearing methods are serving up specialized streams (chars(), codePoints(), lines(), etc) with a method name that is more suitable than "stream". So I think we should drop Streamable and leave the stream() / parallel() methods on Collection (or possibly move them up Iterable).
还有:
我开始认为 Streamable 没有发挥作用.ID喜欢考虑放弃 Streamable，此时最基础的parallel() 的实现在 Collection 中，我还建议我们考虑将其重命名为 parallelStream().
I'm starting to think that Streamable is not carrying its weight. I'd like to consider dropping Streamable, at which point the base-most implementation of parallel() is in Collection, and I'd also suggest we consider renaming that to parallelStream().
在 其他帖子中 他补充道:
如果所有可迭代的东西都是有效的Streamable(因为 Iterable 有一个 stream())方法，以及一切Streamable 实际上是 Iterable(因为您可以将 Spliterator到一个迭代器)，那么它们不是同一个抽象吗?
if everything that is Iterable is effectively Streamable (because Iterable has a stream()) method, and everything Streamable is effectively Iterable (because you can turn a Spliterator into an Iterator), aren't they then the same abstraction?
相关文章