Errata for OCP: Oracle Certified Professional Java SE 8 Programmer II - Chapter 7

[T Vergilio]

First, the question says:

Assuming MyTask is an abstract class that implements the ForkJoinTask interface, what statements about the following code are true?

ForkJoinTask is not an interface, it's an abstract class: https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ForkJoinTask.html

Even with this corrected, I'm still not sure about the code:

public class FindMin extends MyTask {
    private Integer[] elements;
    private int a;
    private int b;

    public FindMin(Integer[] elements, int a, int b) {
        this.elements = elements;
        this.a = a;
        this.b = b;
    }

    public Integer compute() {
        if ((b-a) < 2) {
            return Math.min(elements[a], elements[b]);
        } else {
            int m = a + ((b-a) / 2);
            System.out.println(a + "," + m + "," + b);
            MyTask t1 = new FindMin(elements, a, m);
            int result = t1.fork().join(); //does not compile because the generic type for the class is not defined
            return Math.min(new FindMin(elements, m, b).compute(), result);
        }
    }
}

The fork().join() line does not compile because it cannot cast an Object to an int. It doesn't compile when changing FindMin to extend RecursiveTask either.

The third problem I had was with option C:

C. MyTask inherits RecursiveTask.

Not necessarily. It could extend ForkJoinTask and implement compute() and other methods in a similar way to RecursiveTask, but how can you know for sure that it extends RecursiveTask?

I would appreciate some clarification on these points - this is quite an involved topic, so it could well be me not getting it right.

Thank you.

[Scott Selikoff]

It should say "extends the ForkJoinTask class", not inherits the interface. Errata noted.

The rest of the problem is fine as is. The idea is you have to know the difference between RecursiveTask and RecursiveAction to pick between B and C. Since the compute() method returns a value, C is the best choice candidate. You couldn't also have a compute() method that had a return type of void in a parent class, because this would violate rules for overriding, so B is not possible.

You assume the code does not compile but consider if MyTask includes a generic value in its inheritance structure. Can anyone construct a version of MyTask that would compile? Hint: it can be done in one line.

The rest is covered in the explanation in the solution guide.

[Jeanne Boyarsky]

Scott Selikoff wrote:It should say "extends the ForkJoinTask class", not inherits the interface. Errata noted.

And logged.

Also this is question 9 which I don't see mentioned anywhere in the thread.

[T Vergilio]

Hi Scott,

Thank you very much for the answer.

I see what you mean by one of the parent classes in the inheritance structure having a generic type. Still, you could have this situation:

public abstract class MyTask extends ForkJoinTask<Integer> {
    Integer result;
    protected abstract Integer compute();

    @Override
    public Integer getRawResult() {
        return result;
    }

    @Override
    protected void setRawResult(Integer value) {
        result = value;
    }

    @Override
    protected boolean exec() {
        result = compute();
        return true;
    }
}

Where MyClass wouldn't need to inherit from RecursiveAction or RecursiveTask. The code would still compile and run.

Don't you agree?

Ps: Yes, Jeanne, it's question 9. Sorry, that's what exhaustion does to you

[Scott Selikoff]

I think you might be overthinking this one a little... the code compiles with the following implementation of MyTask:

abstract class MyTask extends RecursiveTask<Integer> {}

As far as skipping RecursiveAction/RecursiveTask, that doesn't really match the text. For the fork/join framework, we use one or the other. The book (and the exam) expects you to use one of these two classes.

[T Vergilio]

Question 17 of the review questions, page 401.

The class doesn't import java.util.concurrent.atomic.*, so compilation will fail because of line w1 (the one where the AtomicInteger is declared), making option D correct.

[Scott Selikoff]

Note that the exam now uses the following disclaimer:

Assume the following:
Missing package and import statements: If sample code do not include package or import statements, and the question does not explicitly refer to these missing statements, then assume that all sample code is in the same package, and import statements exist to support them

[T Vergilio]

Hmm... but the class does import java.util.concurrent.*

If it provides the full code, including one import statement, shouldn't we check to see that all the imports are there?

[Scott Selikoff]

Perhaps for this question but on the exam this would be perfectly acceptable.

[T Vergilio]

On page 393, under "Be able to use the concurrent collection classes":

(...) such as ConcurrentHashMap and ConcurrentDeque.

There is no such thing as ConcurrentDeque. ConcurrentLinkedDeque, maybe?

[Jeanne Boyarsky]

T Vergilio wrote:On page 393, under "Be able to use the concurrent collection classes":

(...) such as ConcurrentHashMap and ConcurrentDeque.

There is no such thing as ConcurrentDeque. ConcurrentLinkedDeque, maybe?

Confirmed and logged in errata.

I also noted your comment about the imports on our private list. Which it's not wrong per se (as one *could* insert the missing import up top), it certainly could be improved

[T Vergilio]

Jeanne Boyarsky wrote:one *could* insert the missing import up top

Indeed, that's a good argument. Luckily the exam isn't that mean!

[John Longer]

Hi

In OCP book option D is mentioned as incorrect answer : The code produces a ForkJoinPool at runtime.

Could you please explain how it is possible not to produce ForkJoinPool instance if task is passed to invoke method of the same ForkJoinPool?

Integer sum = pool.invoke(task);

Thanks

[Jeanne Boyarsky]

John,
Thanks for asking. That answer choice was not the one we intended. The errata says:

#9: Choice D contains a typo and doesn't make sense as written. It should say "The code produces an infinite loop at runtime not the code produces a ForkJoinPool at runtime.

Scott actually noticed this problem after it was too late to get it fixed in the book.

[Evan Certified]

Hello Jeanne,

A bit of errata in errata.

The errata says:

Choice D contains a typo and doesn't make sense as written. It should say "The code produces an infinite loop at runtime not the code produces a ForkJoinPool at runtime.

Could I possibly suggest that you updated errata to have "Chapter 7 mock question" instead of current "Chapter 7" in Chapter column ? Some other errata records have it this way which makes it much easier to find information on the page.

Thanks!

[Evan Certified]

Please disregard my post above. I mixed up page numbers.