java.util.stream.Streamable发生了什么？ [英] What happened to java.util.stream.Streamable?

问题描述

早期 jdk8-ea javadocs 像这样表示有一个 java.util.stream.Streamable 界面，它似乎与流为 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.

现在看来我们仍然坚持供应商< Stream> ，这当然不一样。

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（）等）
，其方法名称比stream更合适。所以我认为我们
应该放弃Streamable并将stream（）/ parallel（）方法留在
Collection（或者可能将它们向上移动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没有承载它的重量。我想
喜欢考虑丢弃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().

在这篇其他帖子他补充说：

if Iterable的所有内容实际上是
Streamable（因为Iterable有一个stream（））方法，所有
Streamable实际上都是Iterable（因为你可以将Spliterator
变成Iterator），不是'然后他们是相同的抽象？

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?

这篇关于java.util.stream.Streamable发生了什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！