¿Por qué findFirst () lanza una NullPointerException si el primer elemento que encuentra es nulo?

¿Por qué esto arroja un java.lang.NullPointerException?

List<String> strings = new ArrayList<>();
        strings.add(null);
        strings.add("test");

        String firstString = strings.stream()
                .findFirst()      // Exception thrown here
                .orElse("StringWhenListIsEmpty");
                //.orElse(null);  // Changing the `orElse()` to avoid ambiguity

El primer artículo stringses null, que es un valor perfectamente aceptable. Además, findFirst()devuelve un Optional , que tiene aún más sentido para findFirst()poder manejar nulls.

EDITAR: actualizado orElse()para que sea menos ambiguo.

La razón de esto es el uso de Optional<T>en la devolución. Opcional no se permite contener null. Esencialmente, no ofrece ninguna forma de distinguir las situaciones "no está ahí" y "está ahí, pero está configurado para null".

Es por eso que la documentación prohíbe explícitamente la situación cuando nullse selecciona en findFirst():

Lanza:

NullPointerException - si el elemento seleccionado es null

Como ya se comentó , los diseñadores de API no asumen que el desarrollador quiera tratar los nullvalores y los valores ausentes de la misma manera.

Si aún desea hacer eso, puede hacerlo explícitamente aplicando la secuencia

.map(Optional::ofNullable).findFirst().flatMap(Function.identity())

a la corriente. El resultado será un opcional vacío en ambos casos, si no hay primer elemento o si el primer elemento lo es null. Entonces, en su caso, puede usar

String firstString = strings.stream()
    .map(Optional::ofNullable).findFirst().flatMap(Function.identity())
    .orElse(null);

para obtener un nullvalor si el primer elemento está ausente o null.

Si desea distinguir entre estos casos, simplemente puede omitir el flatMappaso:

Optional<String> firstString = strings.stream()
    .map(Optional::ofNullable).findFirst().orElse(null);
System.out.println(firstString==null? "no such element":
                   firstString.orElse("first element is null"));

Esto no es muy diferente a su pregunta actualizada. Solo tienes que reemplazar "no such element"con "StringWhenListIsEmpty"y "first element is null"con null. Pero si no te gustan los condicionales, puedes lograrlo también como:

String firstString = strings.stream().skip(0)
    .map(Optional::ofNullable).findFirst()
    .orElseGet(()->Optional.of("StringWhenListIsEmpty"))
    .orElse(null);

Ahora, firstStringserá nullsi un elemento existe pero existe nully será "StringWhenListIsEmpty"cuando no exista ningún elemento.

Puede utilizar java.util.Objects.nonNullpara filtrar la lista antes de buscar

algo como

list.stream().filter(Objects::nonNull).findFirst();

La información siguiente sustituye código findFirst()con limit(1)y reemplaza orElse()con reduce():

String firstString = strings.
   stream().
   limit(1).
   reduce("StringWhenListIsEmpty", (first, second) -> second);

limit()permite que solo 1 elemento alcance reduce. El BinaryOperatorpasado a reducedevuelve ese elemento 1 o "StringWhenListIsEmpty"si ningún elemento alcanza el reduce.

La belleza de esta solución es que Optionalno está asignada y la BinaryOperatorlambda no va a asignar nada.

Se supone que opcional es un tipo de "valor". (lea la letra pequeña en javadoc :) JVM podría incluso reemplazar todo Optional<Foo>con solo Foo, eliminando todos los costos de empaquetado y desembalaje. Un nullFoo significa un vacío Optional<Foo>.

Es un diseño posible permitir Opcional con valor nulo, sin agregar una bandera booleana; solo agregue un objeto centinela. (incluso podría usarse thiscomo centinela; ver la causa Throwable.)

La decisión de que Opcional no puede envolver nulos no se basa en el costo del tiempo de ejecución. Este fue un tema muy controvertido y necesita buscar en las listas de correo. La decisión no convence a todo el mundo.

En cualquier caso, dado que Optional no puede envolver un valor nulo, nos empuja a una esquina en casos como findFirst. Deben haber razonado que los valores nulos son muy raros (incluso se consideró que Stream debería prohibir los valores nulos), por lo tanto, es más conveniente lanzar una excepción en valores nulos en lugar de en streams vacíos.

Una solución es boxear null, por ejemplo

class Box<T>
    static Box<T> of(T value){ .. }

Optional<Box<String>> first = stream.map(Box::of).findFirst();

(Dicen que la solución a todos los problemas de programación orientada a objetos es introducir otro tipo :)