About Question enthuware.ocpjp.v8.2.1896 :

Help and support on OCA OCP Java Programmer Certification Questions
1Z0-808, 1Z0-809, 1Z0-815, 1Z0-816, 1Z0-817

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 »

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: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

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

Post by admin »

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 »

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: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

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

Post by admin »

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 »

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 »

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.

dimitrilc
Posts: 35
Joined: Sat Jun 06, 2020 4:51 pm
Contact:

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

Post by dimitrilc »

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.

Post Reply

Who is online

Users browsing this forum: No registered users and 66 guests