最初に見つかった要素がnullの場合、findFirst（）がNullPointerExceptionをスローするのはなぜですか？

なぜこれがスローするの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

の最初の項目stringsはnull、です。これは完全に許容できる値です。さらに、オプションをfindFirst()返します。これは、sを処理できるようにするためにさらに意味があります。findFirst()null

編集：orElse()あいまいさが少なくなるようにを更新しました。

この理由Optional<T>は、リターンでの使用です。オプションでを含めることはできませんnull。基本的に、「そこにない」と「あるが、に設定されているnull」という状況を区別する方法はありません。

そのため、ドキュメントでnullは、が選択されている場合の状況を明示的に禁止していますfindFirst()。

スロー：

NullPointerException -選択した要素が null

既に述べた、APIの設計者は、開発者が治療を希望していることを前提としていないnull値と不在の値を同じように。

それでもそれを実行したい場合は、シーケンスを適用して明示的に実行できます

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

ストリームに。最初の要素がない場合、または最初の要素がnull。の場合、どちらの場合も結果は空のオプションになります。だからあなたの場合、あなたは使うかもしれません

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

null最初の要素が存在しないかnull。のいずれかである場合に値を取得します。

これらのケースを区別したい場合は、次のflatMap手順を省略できます。

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

これは、更新された質問と大差ありません。あなただけ交換する必要が"no such element"で"StringWhenListIsEmpty"と"first element is null"してnull。ただし、条件文が気に入らない場合は、次のようにすることもできます。

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

さて、firstStringとなりますnull要素が存在するがある場合null、それはなります"StringWhenListIsEmpty"どの要素が存在しない場合。

java.util.Objects.nonNull検索する前にリストをフィルタリングするために使用できます

何かのようなもの

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

次のコードはfindFirst()、に置き換えられlimit(1)、次のように置き換えorElse()られreduce()ます。

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

limit()1つの要素のみがに到達できるようにしますreduce。にBinaryOperator渡されるとreduce、その1つの要素が返されます。または"StringWhenListIsEmpty"、に到達する要素がない場合は返されますreduce。

このソリューションOptionalのBinaryOperator利点は、割り当てられておらず、ラムダが何も割り当てないことです。

オプションは「値」型であると想定されています。（javadocの詳細を読んでください:) JVMは、すべてOptional<Foo>をただFooで置き換えることさえでき、すべてのボックス化およびボックス化解除のコストを取り除きます。AnullはFooは空を意味しますOptional<Foo>。

ブールフラグを追加せずに、null値でOptionalを許可することは可能な設計です-センチネルオブジェクトを追加するだけです。（this歩哨として使用することもできます。Throwable.causeを参照してください）

オプションでnullをラップできないという決定は、実行時のコストに基づいていません。これは非常に争われた問題であり、メーリングリストを掘り下げる必要があります。その決定は誰にとっても説得力があるわけではありません。

いずれにせよ、Optionalはnull値をラップできないため、のような場合にはコーナーに押し込まれfindFirstます。彼らは、null値が非常にまれであると推論したに違いありません（Streamはnull値を禁止する必要があるとさえ考えられていました）。したがって、空のストリームではなくnull値に例外をスローする方が便利です。

回避策は、ボックス化することですnull。

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

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

（彼らは、すべてのOOP問題の解決策は別のタイプを導入することだと言っています:)