Streams versus loops em Java: quando um pipeline é mais claro e quando não é

O que é

A documentação do pacote java.util.stream descreve um stream como uma sequência de elementos que suporta operações de agregação sequenciais e paralelas: uma fonte (coleção, array, gerador), operações intermediárias (filter, map, sorted, distinct, limit) e uma única operação terminal (collect, reduce, forEach, findFirst, count). As operações intermediárias são sempre lazy (preguiçosas): nada é executado até a operação terminal, depois da qual o pipeline fica consumido. A documentação de Stream afirma que um stream deve ser usado apenas uma vez e que a reutilização pode lançar IllegalStateException. A documentação do pacote exige que os parâmetros comportamentais (as lambdas) não interfiram com a fonte, espera que na maioria dos casos sejam stateless (sem estado) e diz que os efeitos colaterais nelas são, em geral, desaconselhados e podem ser eliminados ou reordenados.

Por que importa

Quem vem de Python, JavaScript ou C# LINQ lê pipelines com naturalidade e tende a escrevê-los em todo lugar. O custo aparece em três pontos: depuração (stack traces que atravessam o interior do pipeline), exceções verificadas (uma lambda em map não pode lançar IOException sem encapsulá-la) e legibilidade, quando o pipeline passa a precisar de um índice, de duas sequências percorridas em paralelo ou de terminação antecipada com estado acumulado. Um pipeline que existe só para chamar forEach com efeitos colaterais é um loop com sintaxe mais cara.

Como aplicar

• Use um stream quando o cálculo for uma transformação pura: filtrar, mapear, agrupar (Collectors.groupingBy), juntar (Collectors.joining), somar ou encontrar o primeiro elemento. Dê um nome ao resultado e mantenha o pipeline menor que uma tela.
• Use um loop quando o corpo alterar estado compartilhado, precisar de break ou continue sob várias condições, lançar exceções verificadas, percorrer duas sequências em conjunto ou precisar do índice.
• Devolva toList() (não modificável) a partir de um pipeline, ou Collectors.toCollection(...) quando quem chama precisar de um tipo mutável específico.
• Trate parallel() como uma otimização a ser medida, não como padrão; operações com estado e ordenadas reduzem o seu benefício, e a documentação avisa que a ordem dos efeitos colaterais em execução paralela pode ser surpreendente.
• Não guarde um stream num campo nem o devolva numa API pública, a menos que se espere que quem chama o consuma exatamente uma vez.

Armadilhas

O Optional devolvido por findFirst convida a usar .get() sem verificação. Collectors.toMap lança IllegalStateException com chaves duplicadas, a menos que se forneça uma função de merge, o que a sua documentação afirma. sorted mantém toda a entrada em buffer. Uma lambda que modifica a coleção de origem viola a regra de não interferência e pode produzir resultados errados sem nenhum erro.