Optional y streams: los usos correctos y los abusos más habituales

Optional y la API de streams llegaron juntos con Java 8, y probablemente esa sea su desgracia. Al descubrirse a la vez, se adoptaron como un estilo más que como herramientas, con dos consecuencias visibles en casi todas las bases de código. Por un lado, Optional por todas partes: como parámetro de método, como campo de entidad, anidados unos dentro de otros, serializados en APIs HTTP. Por otro, cadenas de streams de treinta líneas que sustituyen a un bucle de seis y que ningún profiler podrá analizar de forma útil.

El problema no es teórico. Un Optional como campo de entidad rompe la serialización de Java y hace fallar a frameworks de persistencia, porque Optional no implementa Serializable; fue una decisión explícita de sus diseñadores. Un optional.get() sin comprobación previa convierte una NullPointerException en una NoSuchElementException, lo que no mejora absolutamente nada. Y una cadena de streams mal situada dentro de un bucle crítico cuesta varias asignaciones de memoria por elemento allí donde un for no hacía ninguna. Esta lección repasa ambas API separando aquello para lo que fueron diseñadas de lo que se les ha hecho soportar, y después presenta las novedades posteriores a Java 8.