123

Why does this throw a 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

The first item in strings is null, which is a perfectly acceptable value. Furthermore, findFirst() returns an Optional, which makes even more sense for findFirst() to be able to handle nulls.

EDIT: updated the orElse() to be less ambiguous.

neverendingqs
  • 4,006
  • 3
  • 29
  • 57
  • 4
    null isn't perfectly acceptable value... use "" instead – Michele Lacorte Sep 08 '15 at 20:37
  • 1
    @MicheleLacorte although I'm using `String` here, what if it's a list that represents a column in the DB? The value of the first row for that column can be `null`. – neverendingqs Sep 08 '15 at 20:39
  • Yes but in java null isn't acceptable..use query to set null into db – Michele Lacorte Sep 08 '15 at 20:40
  • 18
    @MicheleLacorte, `null` is a perfectly acceptable value in Java, generally speaking. In particular, it is a valid element for an `ArrayList`. Like any other value, however, there are limitations on what can be done with it. "Don't ever use `null`" is not useful advice, as you cannot avoid it. – John Bollinger Sep 08 '15 at 20:47
  • @NathanHughes - I suspect that by the time you call `findFirst()`, there's nothing else you want to do. – neverendingqs Sep 08 '15 at 21:05

5 Answers5

91

The reason for this is the use of Optional<T> in the return. Optional is not allowed to contain null. Essentially, it offers no way of distinguishing situations "it's not there" and "it's there, but it is set to null".

That's why the documentation explicitly prohibits the situation when null is selected in findFirst():

Throws:

NullPointerException - if the element selected is null

Community
  • 1
  • 1
Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
  • 3
    It would be simple to track if a value does exist with a private boolean inside instances of `Optional`. Anyway, I think I'm bordering ranting - if the language doesn't support it, it doesn't support it. – neverendingqs Sep 08 '15 at 20:46
  • Also, I would be happy if you have any alternatives (was hoping for a functional programming-like solution). Time to convert it to a for loop. – neverendingqs Sep 08 '15 at 20:46
  • 2
    @neverendingqs Absolutely, using a `boolean` to differentiate these two situations would make perfect sense. To me, it looks like the use of `Optional` here was a questionable choice. – Sergey Kalinichenko Sep 08 '15 at 20:51
  • 1
    @neverendingqs I can't think of any nice-looking alternative to this, besides [*rolling your own null*](https://en.wikipedia.org/wiki/Null_Object_pattern), which isn't ideal either. – Sergey Kalinichenko Sep 08 '15 at 20:53
  • 1
    I ended up writing a private method that gets the iterator from any `Iterable` type, checks `hasNext()`, and returns the appropriate value. – neverendingqs Sep 08 '15 at 21:02
  • 1
    I think it makes more sense if `findFirst` returns an empty Optional value in PO's case – danny May 02 '19 at 04:38
74

As already discussed, the API designers do not assume that the developer wants to treat null values and absent values the same way.

If you still want to do that, you may do it explicitly by applying the sequence

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

to the stream. The result will be an empty optional in both cases, if there is no first element or if the first element is null. So in your case, you may use

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

to get a null value if the first element is either absent or null.

If you want to distinguish between these cases, you may simply omit the flatMap step:

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

This is not much different to your updated question. You just have to replace "no such element" with "StringWhenListIsEmpty" and "first element is null" with null. But if you don’t like conditionals, you can achieve it also like:

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

Now, firstString will be null if an element exists but is null and it will be "StringWhenListIsEmpty" when no element exists.

Holger
  • 285,553
  • 42
  • 434
  • 765
  • Sorry I realized that my question might have implied I wanted to return `null` for either 1) the first element is `null` or 2) no elements exist inside the list. I have updated the question to remove the ambiguity. – neverendingqs Sep 09 '15 at 14:16
  • 1
    In the 3rd code snippet, an `Optional` may be assigned to `null`. Since `Optional` is supposed to be a "value type", it should never be null. And an Optional should never be compared by `==`. The code may fail in Java 10 :) or when-ever value type is introduced to Java. – ZhongYu Sep 10 '15 at 18:11
  • 1
    @bayou.io: [the documentation](http://docs.oracle.com/javase/8/docs/api/java/lang/doc-files/ValueBased.html) doesn’t say that *references* to value types can’t be `null` and while *instances* should never be compared by `==`, the reference may be tested for `null` using `==` as that’s the *only* way to test it for `null`. I can’t see how such a transition to “never `null`” should work for existing code as even the default value for all instance variables and array elements is `null`. The snippet surely is not the best code but neither is the task of treating `null`s as present values. – Holger Sep 10 '15 at 18:26
  • see [john rose](https://blogs.oracle.com/jrose/entry/value_types_in_the_vm) - *nor can it be compared with the “==” operator, not even with a null* – ZhongYu Sep 10 '15 at 18:31
  • anyways, this is their plan, that `Optional` will not be used like "normal" reference types. so that in future, it can be transitioned to "value type". But people will definitely "misuse" it; the warning on javadoc is certainly very inadequate. – ZhongYu Sep 10 '15 at 18:35
  • 1
    Since this code is using a Generic API, this is what the concept calls a *boxed* representation which can be `null`. However, since such a hypothetical language change would cause the compiler to issue an error here (not break the code silently), I can live with the fact, that it would possibly have to be adapted for Java 10. I suppose, the `Stream` API will look quite different then as well… – Holger Sep 10 '15 at 18:42
  • Add 3rd code snippet, I see `Optional.empty` as a result of `.stream().map(Optional::ofNullable).findFirst().orElse(null)` (**not** `null`) - in case the first element in stream is `null`. – Felix Dec 06 '16 at 12:31
  • What's the purpose of `skip(0)` here? – Ray Jasson Dec 16 '22 at 11:02
  • 2
    @RayJasson good question. I suppose, it’s a leftover from some testing that slipped through. Should have no effect. I removed it. – Holger Dec 16 '22 at 13:40
40

You can use java.util.Objects.nonNull to filter the list before find

something like 

list.stream().filter(Objects::nonNull).findFirst();
Nathan
  • 8,093
  • 8
  • 50
  • 76
Mattos
  • 799
  • 1
  • 9
  • 16
  • 4
    I want `firstString` to be `null` if the first item in `strings` is `null`. – neverendingqs Oct 19 '17 at 20:31
  • 5
    unfortunately it uses ```Optional.of``` which is not null safe. You could ```map``` to ```Optional.ofNullable ``` and then use ```findFirst``` but you will end up with an Optional of Optional – Mattos Oct 20 '17 at 12:38
19

The following code replaces findFirst() with limit(1) and replaces orElse() with reduce(): 

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

limit() allows only 1 element to reach reduce. The BinaryOperator passed to reduce returns that 1 element or else "StringWhenListIsEmpty" if no elements reach the reduce.

The beauty of this solution is that Optional isn't allocated and the BinaryOperator lambda isn't going to allocate anything.

Nathan
  • 8,093
  • 8
  • 50
  • 76
1

Optional is supposed to be a "value" type. (read the fine print in javadoc:) JVM could even replace all Optional<Foo> with just Foo, removing all boxing and unboxing costs. A null Foo means an empty Optional<Foo>.

It is a possible design to allow Optional with null value, without adding a boolean flag - just add a sentinel object. (could even use this as sentinel; see Throwable.cause)

The decision that Optional cannot wrap null is not based on runtime cost. This was a hugely contended issue and you need to dig the mailing lists. The decision is not convincing to everybody.

In any case, since Optional cannot wrap null value, it pushes us in a corner in cases like findFirst. They must have reasoned that null values are very rare (it was even considered that Stream should bar null values), therefore it is more convenient to throw exception on null values instead of on empty streams.

A workaround is to box null, e.g. 

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

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

(They say the solution to every OOP problem is to introduce another type :)

ZhongYu
  • 19,446
  • 5
  • 33
  • 61
  • 2
    There is no need to create another `Box` type. The `Optional` type itself can serve this purpose. See [my answer](http://stackoverflow.com/a/32476601/2711488) for an example. – Holger Sep 09 '15 at 10:08
  • @Holger - yes, but that might be confusing since it's not the intended purpose of Optional. In OP's case, `null` is a valid value like any other, no special treatment for it. (until sometime later:) – ZhongYu Sep 09 '15 at 15:17