Stream <T>がIterable <T>を実装しないのはなぜですか？

Java 8では、クラスStream <T>があり、奇妙なことにメソッドがあります

Iterator<T> iterator()

そのため、このメソッドを必要とするIterable <T>インターフェースの実装が期待されますが、そうではありません。

foreachループを使用してストリームを反復処理する場合は、次のようにする必要があります

public static Iterable<T> getIterable(Stream<T> s) {
    return new Iterable<T> {
        @Override
        public Iterator<T> iterator() {
            return s.iterator();
        }
    };
}

for (T element : getIterable(s)) { ... }

ここで何か不足していますか？

人々はすでに同じことをメーリングリストで質問していますhave 。主な理由は、Iterableにもre-iterableセマンティクスがあるのに対し、Streamにはないということです。

主な理由は、それIterableが再利用性を意味するのに対して、Stream一度だけしか使用できないものであると思いますIterator。

場合はStream、拡張Iterableは、受信したときに、既存のコードは驚くかもしれませんIterableスローそのException彼らが二度目にfor (element : iterable)。

をに変換するStreamにはIterable、次のようにします

Stream<X> stream = null;
Iterable<X> iterable = stream::iterator

をStream期待するメソッドにを渡すにはIterable、

void foo(Iterable<X> iterable)

単に

foo(stream::iterator) 

しかし、おそらくおかしく見えます。もう少し明確にする方がいいかもしれません

foo( (Iterable<X>)stream::iterator );

私はそれStreamExがIterable（およびStream）を実装していること、およびから欠けている他の非常に素晴らしい機能のホストを指摘したいと思いStreamます。

for次のように、ループでストリームを使用できます。

Stream<T> stream = ...;

for (T x : (Iterable<T>) stream::iterator) {
    ...
}

（実行 このスニペットをここでてください）

（これはJava 8機能インターフェースキャストを使用します。）

（これは上記のコメントの一部（例：Aleksandr Dubinsky）でカバーされていますが、それを解答に引き出してもっと見やすくしたいと思いました。）

kennytmは、aをStreamとして扱うことが安全ではない理由を説明しIterable、Zhong Yuは、 a Streamをinとして使用することをIterable安全でない方法で許可する回避策を提供しました。両方の世界のベストを得ることが可能です：仕様で行われたすべての保証を満たすIterableから再利用StreamできIterableます。

注：SomeTypeはここではタイプパラメータではありません。適切なタイプ（たとえばString）に置き換えるか、リフレクションを使用する必要があります

Stream<SomeType> stream = ...;
Iterable<SomeType> iterable = stream.collect(toList()):

主な欠点が1つあります。

遅延イテレーションのメリットは失われます。現在のスレッドのすべての値をすぐに反復することを計画した場合、オーバーヘッドは無視できます。ただし、部分的または別のスレッドでのみ反復することを計画した場合、この即時かつ完全な反復は意図しない結果をもたらす可能性があります。

もちろん、大きな利点は、を再利用できることですがIterable、1回し(Iterable<SomeType>) stream::iteratorか使用できません。受信コードがコレクションを何度も繰り返す場合、これは必要なだけでなく、パフォーマンスにとっても有益です。

Stream実装していませんIterable。の一般的な理解Iterableは、何度も何度も繰り返すことができるものです。Stream再生できない場合があります。

私が考えることができる唯一の回避策は、ストリームに基づくイテラブルも再生可能である場合、ストリームを再作成することです。Supplier新しいイテレータが作成されるたびに、ストリームの新しいインスタンスを作成するために以下を使用しています。

    Supplier<Stream<Integer>> streamSupplier = () -> Stream.of(10);
    Iterable<Integer> iterable = () -> streamSupplier.get().iterator();
    for(int i : iterable) {
        System.out.println(i);
    }
    // Can iterate again
    for(int i : iterable) {
        System.out.println(i);
    }

サードパーティのライブラリを使用することを気にしない場合、cyclops-reactは、StreamとIterableの両方を実装し、再生も可能なStreamを定義します（記述されたkennytmの問題の解決）。

 Stream<String> stream = ReactiveSeq.of("hello","world")
                                    .map(s->"prefix-"+s);

または：-

 Iterable<String> stream = ReactiveSeq.of("hello","world")
                                      .map(s->"prefix-"+s);

 stream.forEach(System.out::println);
 stream.forEach(System.out::println);

[開示私はc​​yclops-reactの主要開発者です]

完璧ではありませんが、動作します：

iterable = stream.collect(Collectors.toList());

それは、ストリームからすべてのアイテムを取得し、その中にそれらを配置しますので、完璧ではないList正確に何をされていない、IterableそしてStream約あります。彼らは怠惰であることになっています。

次のStream<Path>ようにして、フォルダー内のすべてのファイルを反復処理できます。

Path path = Paths.get("...");
Stream<Path> files = Files.list(path);

for (Iterator<Path> it = files.iterator(); it.hasNext(); )
{
    Object file = it.next();

    // ...
}