相关文章推荐
逃课的水龙头  ·  Windows 应用 SDK ...·  1 年前    · 
安静的火柴  ·  Kotlin ...·  1 年前    · 
Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

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.

@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 8, 2015 at 20:39 @MicheleLacorte, null is a perfectly acceptable value in Java, generally speaking. In particular, it is a valid element for an ArrayList<String>. 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 8, 2015 at 20:47 @NathanHughes - I suspect that by the time you call findFirst(), there's nothing else you want to do. – neverendingqs Sep 8, 2015 at 21:05

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

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 8, 2015 at 20:46 @neverendingqs Absolutely, using a boolean to differentiate these two situations would make perfect sense. To me, it looks like the use of Optional<T> here was a questionable choice. – Sergey Kalinichenko Sep 8, 2015 at 20:51 @neverendingqs I can't think of any nice-looking alternative to this, besides rolling your own null, which isn't ideal either. – Sergey Kalinichenko Sep 8, 2015 at 20:53 I ended up writing a private method that gets the iterator from any Iterable type, checks hasNext(), and returns the appropriate value. – neverendingqs Sep 8, 2015 at 21:02

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.

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 9, 2015 at 14:16 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, 2015 at 18:11 @bayou.io: the documentation 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 nulls as present values. – Holger Sep 10, 2015 at 18:26 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, 2015 at 18:42 @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, 2022 at 13:40 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, 2017 at 12:38

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.

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 :)

There is no need to create another Box type. The Optional type itself can serve this purpose. See my answer for an example. – Holger Sep 9, 2015 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 9, 2015 at 15:17

Thanks for contributing an answer to Stack Overflow!

  • Please be sure to answer the question. Provide details and share your research!

But avoid

  • Asking for help, clarification, or responding to other answers.
  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.