Enthuware

So I chose...

<An Optional containing 13, 14, or 15>:Optional[13]

Then the test marked my answer as wrong, saying that I should have chosen:
<An Optional containing 13, 14, or 15>:<An Optional containing 13, 14, or 15>

However, I tested the code and it does in fact print:
Optional[13]:Optional[13]
However, when testing, I found out that it printed (as expected)
Optional[50]:Optional[13] when raising the "15"-value passed to rangeClosed in both examples.

Notice that the Optional[13] after the : did not change!

So I think the answer to this question is really misleading and it should be <An Optional containing 13, 14, or 15>:Optional[13].

Did you read the explanation?

The second stream is sequential and therefore, ideally, findAny should return the first element. However, findAny is deliberately designed to be non-deterministic. Its API specifically says that it may return any element from the stream. If you want to select the first element, you should use findFirst.

Paul.

Yes, but reading and interpreting the Javadoc and seeing the actual code execute are 2 different things:

The Javadoc actually kind of reveals this behavior:
"The behavior of this operation is explicitly nondeterministic; it is free to select any element in the stream. This is to allow for maximal performance in parallel operations; the cost is that multiple invocations on the same source may not return the same result. (If a stable result is desired, use findFirst() instead.)"

I do get the reasoning behind this question and answer: in a realworld scenario, please pick findFirst, so you are very sure of its behavior in both sequential and parallel contexts.

However, when testing this code with huge datasets, and you still get Optional[13] and when decompiling and you see, in case of the sequential one, an implementation that actually makes sure 13 is always chosen, the answer really is wrong.

I'm sorry but I do not agree with your argument. This is essentially a question about the API. When you use an API, you are bound by whatever is promised by the provider. Here, it clearly says that it is free to return any element. So the size of your test data set and result is totally irrelevant.
What if you update your jdk to a newer version that doesn't return the first element? or what if you run it on a jdk implemented by another company that doesn't return the first element? It would still be compliant.

And then still, executing that piece of code should reveal the correct answer. And now it does not.

I chose
<An Optional containing 13, 14, or 15>:Optional[13]
as well. I remembered somewhere in the OCP book I was reading by Boyarsky and Selikoff it had a similar example, here it is:

(Page 372 to 373)
"Let's take a look at the results of findAny() applied to a serial stream:
System.out.println(Arrays.asList(1,2,3,4,5,6).stream().findAny().get());
This code consistently outputs the first value in the serial stream, 1.
... (a bit later, after comparing with parallel streams)
You can see that with parallel streams, the results of findAny() are no longer predictable.
"

This implies that with a serial stream, the result will always be the first value in the stream, hence why I chose that option.

However, I guess Java doesn't specify this result anywhere, so I would agree that that is the incorrect answer, I'm just saying it's weird having that example be inconsistent with the API.

I also chose
<An Optional containing 13, 14, or 15>:Optional[13]
as well.

Logically, I think findAny() is pretty much pointless on a serial stream because functionally, it is the same thing as findFirst() (java 11).
findAny() was most likely designed to be used on parallel streams only.

The question was specifically asking what the code will print, unless the test writer can prove that the 2nd stream will print anything other than Optional[13] (Java 11), <An Optional containing 13, 14, or 15>:Optional[13] should be the correct answer.

But there is no point in nitpicking too much on a mock question.

Enthuware also has an important point that I find very valuable,

When you use an API, you are bound by whatever is promised by the provider.

Java can decide to change the implementation of findAny() for sequential streams that would still stay true to their original doc. If you carelessly used findAny() on a sequential stream in your code in lieu of findFirst(), then it is your fault that your code now behave unpredictably because you did not follow the doc.

The important thing is that this question helped us reinforce our knowledge. That's what's most important.