Por que findFirst () lança um NullPointerException se o primeiro elemento que encontra é nulo?

Por que isso lança um 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

O primeiro item stringsé null, que é um valor perfeitamente aceitável. Além disso, findFirst()retorna um Optional , o que faz ainda mais sentido para findFirst()poder manipular nulls.

EDIT: atualizado orElse()para ser menos ambíguo.

A razão para isso é o uso de Optional<T>na devolução. Opcional não pode conter null. Essencialmente, ele não oferece nenhuma maneira de distinguir situações "não está lá" e "está lá, mas está definido para null".

É por isso que a documentação proíbe explicitamente a situação quando nullé selecionado em findFirst():

Lança:

NullPointerException - se o elemento selecionado for null

Conforme já discutido , os designers de API não presumem que o desenvolvedor deseja tratar nullvalores e valores ausentes da mesma maneira.

Se ainda quiser fazer isso, você pode fazê-lo explicitamente aplicando a sequência

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

para o riacho. O resultado será um opcional vazio em ambos os casos, se não houver um primeiro elemento ou se o primeiro elemento for null. Então, no seu caso, você pode usar

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

para obter um nullvalor se o primeiro elemento estiver ausente ou null.

Se você quiser distinguir entre esses casos, pode simplesmente omitir a flatMapetapa:

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"));

Isso não é muito diferente da sua pergunta atualizada. Você apenas tem que substituir "no such element"por "StringWhenListIsEmpty"e "first element is null"por null. Mas se você não gosta de condicionais, também pode obtê-lo como:

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

Agora, firstStringserá nullse um elemento existe, mas é nulle será "StringWhenListIsEmpty"quando nenhum elemento existir.

Você pode usar java.util.Objects.nonNullpara filtrar a lista antes de encontrar

algo como

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

O texto seguinte substitui código findFirst()com limit(1)e substitui orElse()com reduce():

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

limit()permite que apenas 1 elemento alcance reduce. O BinaryOperatorpassado para reduceretorna aquele 1 elemento ou então, "StringWhenListIsEmpty"se nenhum elemento alcançar o reduce.

A beleza dessa solução é que Optionalnão está alocado e o BinaryOperatorlambda não vai alocar nada.

Opcional deve ser um tipo de "valor". (leia as letras miúdas em javadoc :) JVM poderia até mesmo substituir tudo Optional<Foo>por apenas Foo, removendo todos os custos de encaixotamento e desembalagem. Um nullFoo significa um vazio Optional<Foo>.

É um design possível para permitir Optional com valor nulo, sem adicionar um sinalizador booleano - basta adicionar um objeto sentinela. (pode até ser usado thiscomo sentinela; consulte Throwable.cause)

A decisão de que Opcional não pode agrupar nulo não é baseada no custo de tempo de execução. Este foi um problema muito discutido e você precisa cavar as listas de discussão. A decisão não convence a todos.

Em qualquer caso, uma vez que Optional não pode envolver um valor nulo, ele nos empurra para um canto em casos como findFirst. Eles devem ter raciocinado que os valores nulos são muito raros (foi até considerado que o Stream deveria barrar os valores nulos), portanto, é mais conveniente lançar uma exceção em valores nulos em vez de em fluxos vazios.

Uma solução alternativa é encaixotar null, por exemplo

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

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

(Eles dizem que a solução para cada problema OOP é introduzir outro tipo :)