¿Dónde debería usarse Optional, y dónde es un error?

Optional se diseñó como tipo de retorno para métodos que pueden legítimamente no tener resultado, para que quien llama no pueda ignorar la ausencia. Encaja mal en campos, parámetros de constructor y argumentos de método, y no debería envolver una colección, ya que una lista vacía ya dice que aquí no hay nada. Llamar a get sin comprobar echa por tierra el propósito; usa map, filter, orElseGet u orElseThrow con una excepción con significado.

Existe para que la firma de un método pueda decir esto quizá no devuelva nada, algo que un tipo de retorno nulable nunca comunicó. Así que las búsquedas de estilo repositorio devuelven un Optional y quien llama está obligado a tratarlo. Donde se tuerce es cuando la gente lo pone en todas partes. Como campo añade un objeto por instancia y no es serializable, lo que causa problemas reales en entidades y payloads. Como parámetro solo le da a quien llama tres estados que pensar en vez de dos, así que uso una sobrecarga. Y un método que devuelve una colección devuelve una colección vacía, nunca un Optional de una lista, porque vacía ya significa lo mismo. En cuanto al estilo, si escribo isPresent seguido de get he escrito una comprobación de nulos con ceremonia extra, así que encadeno: map a lo que quiero, filter, y luego orElseThrow con una excepción de dominio que diga qué id no se encontró. Lo único que no haría es usarlo como sustituto general del nulo en una base de código existente, porque el estilo mezclado es peor que cualquiera de las dos convenciones por separado.