Elana Abelev

I see, thank you.  

Ooops, forgot to mention that it's the Sybex/Wiley book

Initially answered that the code given will not compile (but not because of the reason given in the answer choice (which is also correct)).  I thought compilation will fail because of the call

s.execute(() -> r2.getAnswer(r1));  

the getAnswer function in the question has a return type of String, and Executor.execute expects Runnable (with void return type), so I expected the lambda expression to be interpreted as a Callable (because of String return type in getAnswer ) and compilation to fail.  That wasn't the case.

I tried it out with following code, the workings of which I don't quite understand.  Please, explain why the //compiles lines compile and the //does not compile do not...   The ones that do not give error "bad return type in lambda expression, String cannot be converted to void".  I understand that very well.
But what makes the lines that compiles work?  How does the call to method test(), which returns a String ends up compatible with Runnable's void run ()  (or, if judging by lack of compilation error, the return gets "converted to void")?  

... String test () {   return ""; } ExecutorService es = Executors.newSingleThreadExecutor(); String y = new String (""); es.execute (() -> test());   //1.  compiles! es.execute (() -> new String("");   //2.  compiles! es.execute (() -> y); //3.  does not compile!! es.execute (() -> ""); //4.  does not compile!!

Thanks!

Roel De Nijs wrote:

Elana Abelev wrote:I haven't figured out how to modify the title of the post, otherwise I'd do that.  Thanks!

I have added it for you.

Thanks!!!

Another typo report for the same exam.  The question about Platypus and UsesBeak

Option A should say "Platypus has-a UsesBeak", not "Platypus has-a Beak".

Roel De Nijs wrote:

Elana Abelev wrote:I haven't seen this in errata, and apologies if it's a duplicate post or my misunderstanding.

It is always useful to at least mention which study guide this errata report is about. And preferrably you add it into the subject (e.g. between parantheses)

You are right!  This is for the Sybex Wiley Oracle OCPJP 1Z0-809 online mock exam.

I haven't figured out how to modify the title of the post, otherwise I'd do that.  Thanks!

OK, I just "got" option E.  It means whether private modifier is necessary or not, not whether it has to be changed.  So forget the second error.  First typo still remains, and doesn't affect the answer.

Thanks.

Hi,
I haven't seen this in errata, and apologies if it's a duplicate post or my misunderstanding.

One of the questions on mock exam 3 has a couple of errors.

The question about public enum Suit and Color (enum within enum question)...

1. Option D states that "Color.Black should be replaced by BLACK on line 2".  It should be Color.BLACK in the option.
2. Option E states that  "Color enum on line 4 should be declared private".  It is already private in the provided example code.  

I think that Option E typo could, potentially, affect the answer choice.  Either the access modifier in the code or in the option should be changed, to make option E a viable option.

Thank you!

OK, but the book doesn't say "unless initialized with a constant expression".   It just gives a blanket "no static fields" statement, which would imply (to many, I'd think) that final fields are included in this definition.  How in the world would one know that final fields are an exception to this rule (without reading the JLS prior to the book)?  It is very misleading.

Yes!  So why does the book say that inner classes cannot declare static fields?

First of all, a major thank you to Jeanne Boyarsky and Scott Selikoff for monitoring these forums, and specifically to Jeanne who has personally answered several of my "OMG-I-can't-believe-I-didn't-see-that" questions.

Here is another one.  
p25, Member Inner Classes definitions.  The book states that

Member Inner Classes "cannot declare static fields or methods"  (fourth bullet in that section).

However, the following compiles
public class Test {    class A {        static final int B = 0;    } }

So...  It seems they can, IF these static fields are marked final.  (Couldn't get a static final method declaration to compile, so I guess this quirk only applies to fields).
I found a couple threads on these boards that discuss this, but none that address what the book states (that I found, at least).   I think it's an important fact one should be aware of when studying for the exam.  Why has the book omitted it?

Thank you in advance!

Hi, everyone!

On p.432 (Ch 8), the example on serialization says that the type of both animals after deserialization would be 'P' (even though one is initialized with type='P' and the other with type ='T' on page 428).  I tried it and indeed in my examples one is P and the other is T.   Please, explain why they're both type P in the book.

Thank you!

OK, I can see that this has been mentioned a year ago already.  It didn't come up in my search before I posted the question, but it did come up in "related topics" after I posted this.  So, please, disregard.

Thank you.

Hi, All!  I have a question on ch4 review q.14. in the Boyarsky/Selikoff OCP review book

The correct answer to q. 14 is D.  In option D we have

Stream<Integer> s2 = ds.mapToInt(x->x);

The answer is correct, however, I think the explanation is incomplete.  In the explanation, it states that the reason the above does not compile is because an explicit cast to in is required inside the lambda.  While that is true, it's not the only reason that line does not compile.  In other words, if you put in the explicit cast, it would STILL not compile because the return type of mapToInt is IntStream, and the above line is trying to assign that to Stream<Integer>, which are incompatible.   I think the explanation needs to be updated to include this point to bring attention to return types of mapping functions.  This second error can be fixed by either changing the result type to IntStream, or by calling mapToObj on ds.

I could be wrong .  Thank you for reading.  

Hi, All,

I'm thinking out loud here, and hopefully no one is offended by my comments.

I'm studying for the OCP with the Boyarsky/Selikoff book, and overall I find it and excellent resource.  I'm also reading other books in parallel.  In Chapter 2 of Boyarsky/Selikoff they are talking about the Singleton pattern, and on p81 in a "Real World Scenario" they mention the double ckecked locking mechanism for lazy initialization (and do use the volatile keyword).  The book specifically states that "The solution is to use double-checked locking, a design pattern ......".    However, Java Concurrency in Practice (another great resource) states that double checked locking is an outdated pattern for lazy initialization (even if it would work properly with the volatile keyword), and that a better mechanism for lazy initialization would be the "lazy initialization holder class idiom".  In fact, JCP actually lists double ckecked locking as one of the "bugs" that FindBugs looks for when analyzing code for bug patterns.

So, any thoughts?  I understand that this topic is beyond the scope of the exam, but I'm just curious what the experts think about this.  Why talk about double checked locking when there is a better pattern out there?  Or maybe it's not better and JCP is wrong?  

Thanks