Optional et flux : les usages corrects et les abus courants

Optional et l'API des flux sont arrivés ensemble en Java 8, et c'est probablement leur malchance. Découverts en même temps, ils ont été adoptés comme un style plutôt que comme des outils, avec deux conséquences visibles dans presque toutes les bases de code. D'un côté des Optional partout : en paramètre de méthode, en champ d'entité, imbriqués les uns dans les autres, sérialisés dans des API HTTP. De l'autre des chaînes de flux de trente lignes qui remplacent une boucle de six et qu'aucun profileur ne pourra plus analyser utilement.

Le problème n'est pas théorique. Un Optional en champ d'entité casse la sérialisation Java et fait échouer des cadres de persistance, parce que Optional n'implémente pas Serializable — c'était une décision explicite de ses concepteurs. Un optional.get() sans vérification préalable transforme un NullPointerException en NoSuchElementException, ce qui n'améliore strictement rien. Et une chaîne de flux mal placée dans une boucle chaude coûte plusieurs allocations par élément là où un for n'en faisait aucune. Cette leçon reprend ces deux API en séparant ce pour quoi elles ont été conçues de ce qu'on leur a fait subir, puis présente les ajouts postérieurs à Java 8.