Flux Java contre boucles : quand un pipeline est plus clair, et quand il ne l'est pas

Ce que c'est

La documentation du paquetage java.util.stream décrit un flux comme une séquence d'éléments prenant en charge des opérations d'agrégation séquentielles et parallèles : une source (collection, tableau, générateur), des opérations intermédiaires (filter, map, sorted, distinct, limit) et une seule opération terminale (collect, reduce, forEach, findFirst, count). Les opérations intermédiaires sont toujours paresseuses ; rien ne s'exécute avant l'opération terminale, après laquelle le pipeline est consommé. La documentation de Stream indique qu'un flux ne devrait être exploité qu'une seule fois et que sa réutilisation peut lever une IllegalStateException. La documentation du paquetage exige que les paramètres comportementaux (les lambdas) n'interfèrent pas avec la source, s'attend dans la plupart des cas à ce qu'ils soient sans état, et indique que leurs effets de bord sont en général déconseillés et peuvent être supprimés ou réordonnés.

Pourquoi c'est important

Les personnes venues de Python, de JavaScript ou de LINQ en C# lisent les pipelines naturellement et tendent à en écrire partout. Le coût se manifeste à trois endroits : le débogage (des traces de pile traversant les mécanismes internes du pipeline), les exceptions vérifiées (une lambda dans map ne peut pas lever une IOException sans l'envelopper) et la lisibilité dès que le pipeline a besoin d'un index, de deux séquences parcourues en tandem ou d'une sortie anticipée avec état accumulé. Un pipeline qui n'existe que pour appeler forEach avec des effets de bord est une boucle écrite dans une syntaxe plus coûteuse.

Comment l'appliquer

• Utiliser un flux lorsque le calcul est une transformation pure : filtrage, transformation, regroupement (Collectors.groupingBy), jonction (Collectors.joining), somme, ou recherche du premier élément. Nommer le résultat et garder un pipeline tenant sur moins d'un écran.
• Utiliser une boucle lorsque le corps modifie un état partagé, a besoin de break ou de continue selon plusieurs conditions, lève des exceptions vérifiées, itère sur deux séquences en tandem, ou a besoin de l'index.
• Renvoyer toList() (non modifiable) depuis un pipeline, ou Collectors.toCollection(...) lorsque l'appelant a besoin d'un type mutable particulier.
• Considérer parallel() comme une optimisation à mesurer, et non comme un choix par défaut ; les opérations avec état et ordonnées en réduisent le bénéfice, et la documentation avertit que l'ordre des effets de bord sous exécution parallèle peut être surprenant.
• Ne pas stocker un flux dans un champ ni en renvoyer un depuis une API publique, sauf si l'appelant est censé le consommer exactement une fois.

Pièges

L'Optional renvoyé par findFirst invite à appeler .get() sans vérification. Collectors.toMap lève une IllegalStateException en cas de clés dupliquées, sauf si une fonction de fusion est fournie, comme l'indique sa documentation. sorted met en tampon l'intégralité de l'entrée. Une lambda qui modifie la collection source viole la non-interférence et peut produire des résultats erronés sans lever d'erreur.