About Question enthuware.ocpjp.v8.2.1896 :

Moderator: admin

Post Reply
Tanooki
Posts: 9
Joined: Wed Dec 28, 2016 12:35 pm
Contact:

About Question enthuware.ocpjp.v8.2.1896 :

Post by Tanooki » Wed Dec 28, 2016 5:27 pm

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].

admin
Site Admin
Posts: 8465
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocpjp.v8.2.1896 :

Post by admin » Thu Dec 29, 2016 1:18 am

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.
If you like our products and services, please help us by posting your review here.

Tanooki
Posts: 9
Joined: Wed Dec 28, 2016 12:35 pm
Contact:

Re: About Question enthuware.ocpjp.v8.2.1896 :

Post by Tanooki » Thu Dec 29, 2016 3:02 am

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.

admin
Site Admin
Posts: 8465
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocpjp.v8.2.1896 :

Post by admin » Thu Dec 29, 2016 7:17 am

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.
If you like our products and services, please help us by posting your review here.

Tanooki
Posts: 9
Joined: Wed Dec 28, 2016 12:35 pm
Contact:

Re: About Question enthuware.ocpjp.v8.2.1896 :

Post by Tanooki » Thu Dec 29, 2016 7:50 am

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

DavidL
Posts: 1
Joined: Wed Jan 02, 2019 9:50 am
Contact:

Re: About Question enthuware.ocpjp.v8.2.1896 :

Post by DavidL » Wed Jan 02, 2019 9:56 am

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.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests