Em bibliotecas pré-Java 8 pesadas para lambda como Guava, as saídas usam interfaces comuns do Java Collection Framework, portanto é fácil transmiti-las para APIs externas / internas e ainda aproveitar uma computação lenta se o método da biblioteca o fizer (por exemplo, lazy filter()e transform()).
No entanto, em Java 8 Streams, a chamada para obter um Collection/ Mapé terminal (ou seja ansioso) e que também irá alocar novas estruturas de dados para armazenar os resultados.
Para cálculos complicados com vários estágios e padrão de estratégia no meio, isso causa muitas alocações desnecessárias devido aos resultados intermediários.
Então, as pessoas pensam que é uma boa prática para APIs internas (ou seja, estratégias de padrão de estratégia) obter e retornar Streams ou devo apenas recorrer às APIs Guava preguiçosas, mas não simplificadas (trocadilhos, acho?)?
Editar:
Minha principal preocupação Streamé que ele só pode ser consumido uma vez e passar algo como um Supplier<Stream<X>>parece extremamente complicado. Quase o empurra apenas para passar em um Collectione depois devolvê- stream()lo (e pagando o custo de uma avaliação ágil naquele momento).
Respostas:
Preguiça no Java 8 Streams funciona da mesma maneira que costumava para os Iterables na Guava: você precisa passar o Iterable para ficar preguiçoso e a avaliação acontece, depois que você cria uma coleção a partir do Iterator. Streams e Iteradores podem ser consumidos apenas uma vez.
Portanto, para as interfaces de método, a maneira mais geral (permitindo a preguiça) é usar a interface Stream (sempre que você tivesse usado o Iterable antes). Como o @Philipp diz, isso permite que eles sejam usados nos pipelines de Stream.
Felizmente, como o Stream agora é uma interface padrão oficial do Java, haverá mais e mais bibliotecas e funções que podem trabalhar eficientemente diretamente no Streams.
fonte