Errata for OCA/OCP Java SE 7 Programmer I & II Study Guide (K&B7)

[Roel De Nijs]

J Deckarm wrote:chapter 15, page 907
"Unlike prepared statements, stored procedures and functions must exist before a CallableStatement can be executed on them."
=> This sentence seems to be somewhat confusing; sounds as if CallableStatement would execute PreparedStatement as well

Thanks for the suggestion! But the previous sentence clearly states that a CallableStatement is used to execute a named stored procedure or function. So I think it's pretty obvious a prepared statement can't be executed using a CallableStatement.

Kind regards,
Roel

[Roel De Nijs]

J Deckarm wrote:chapter 15, page 923
"A transaction includes all of the SQL queries you execute until either..."
=> While it might be a terminology debate, "queries" could seem to indicate SELECTs only.

Added to the errata overview.

[Mark Kevin]

On the fifth line down on page 145, in the comment, isn't the static variable named frogCount, rather than FrogCount?

[Roel De Nijs]

Mark Kevin wrote:On the fifth line down on page 145, in the comment, isn't the static variable named frogCount, rather than FrogCount?

Added to the errata overview.

[Mark Kevin]

I could be wrong, but on page 145, in the big paragraph in the top half of the page, I see references in three places to the 'static method' but all I see in the preceding code is a static variable, frogCount. Where is the static method the text refers to? Sorry to bother you.

1) ... and then use the f reference to invoke the static method!

2) But even though we are using a specific Frog instance to access the static method ...

3) ... and so the Frog class static method is run ...


Am I seeing things?

[Roel De Nijs]

Mark Kevin wrote:I could be wrong, but on page 145, in the big paragraph in the top half of the page, I see references in three places to the 'static method' but all I see in the preceding code is a static variable, frogCount. Where is the static method the text refers to? Sorry to bother you.

You are correct! No need to be sorry

Added to the errata overview.

[Roel De Nijs]

J Deckarm wrote:chapter 14, page 818
"A ForkJoinTask has many methods (most of which you will never use), but the following methods are important: compute(), fork(), and join()"
=> This might be somewhat misleading, because the compute() methods are in fact not in the ForkJoinTask class itself, but its subclasses RecursiveTask and RecursiveAction

Added to the errata overview.

[J Deckarm]

chapter 12, page 698
The example would seem more complete if in class Bar the doStuff(Foo f) method would have a body of calling f.foof(); so that the overriden method would be really utilized

[J Deckarm]

CD mock exams, objective 6, OCP Exam 1, question 6
Answer E states "Never throw an AssertionError explicitly" is not marked as a correct answer, yet in the explanation it states "throwing an AssertionError explicitly is considered bad practice"

[Roel De Nijs]

J Deckarm wrote:chapter 12, page 698
The example would seem more complete if in class Bar the doStuff(Foo f) method would have a body of calling f.foof(); so that the overriden method would be really utilized

Thanks for the suggestion! Calling the floof() method is not key in this code snippet, the only thing required is having an object which IS-A Foo to pass to the doStuff() method of class Bar. The actual implementation of the doStuff() method is not important at all.

Kind regards,
Roel

[Roel De Nijs]

J Deckarm wrote:CD mock exams, objective 6, OCP Exam 1, question 6
Answer E states "Never throw an AssertionError explicitly" is not marked as a correct answer, yet in the explanation it states "throwing an AssertionError explicitly is considered bad practice"

Answer E is indeed incorrect, but the explanation is wrong. Should be something like: Explicitly throwing an AssertionError is sometimes an acceptable alternative. Another valid situation could be

class ThrowAssertionError {
    public String getCode(int idSize) {
        switch (idSize) {
        case 0: return "S";
        case 1: return "M";
        case 2: return "L";
        }
        throw new AssertionError("idSize[" + idSize + "] unknown");
    }
}

If you would use an assert statement, the code won't compile because the getCode() method must provide a return value.

Added to the errata overview.

[J Deckarm]

chapter 12, self-test q6
explanation says: "The variable referenced by f is an instance of an anonymous subclass of Bar..."
=> Should be rather likely "The object referenced by the variable f..." (just as two sentences earlier regarding variable t)

[Roel De Nijs]

J Deckarm wrote:chapter 12, self-test q6
explanation says: "The variable referenced by f is an instance of an anonymous subclass of Bar..."
=> Should be rather likely "The object referenced by the variable f..." (just as two sentences earlier regarding variable t)

Added to the errata overview.

[Mark Kevin]

K & B, OCA 7, page 192

In the middle of the page, shouldn't:

a.height = 10 be a1.height = 10

a.height = 30 be a1.height = 30 ?

In other words, 'a' should be 'a1' ?

[J Deckarm]

CD mock exams, objective 1, OCP Exam 1, question 2
While the explanation seems to be a valid statement, the compilation seems to fail on the first place because of super cannot be used in a static context; regardless whether the method in the parent class is static or non-static

[Roel De Nijs]

Mark Kevin wrote:K & B, OCA 7, page 192

In the middle of the page, shouldn't:
...
In other words, 'a' should be 'a1' ?

Added to the errata overview.

[Roel De Nijs]

Chapter 15, page 842: Although the main JDBC interfaces define a contract, it seems that not all versions of every vendor's JDBC implementation seems to be fully compliant with the contract (examples: here, here and here). So a note should be added somewhere in this (introductory) section to make readers aware of these inconsistencies (so they are not surprised/confused when executing code snippets).

Suggested by J Deckarm in one of the aforementioned examples.

Confirmed & added to the errata overview.

[Roel De Nijs]

J Deckarm wrote:CD mock exams, objective 1, OCP Exam 1, question 2
While the explanation seems to be a valid statement, the compilation seems to fail on the first place because of super cannot be used in a static context; regardless whether the method in the parent class is static or non-static

Added to the errata overview.

[J Deckarm]

chapter 10, page 571, answer 5
"Not shown is a class implementing class G that actually creates the object."
=> Should be likely "extending class G"

[J Deckarm]

CD mock exams, objective 3, OCP Exam 1, question 3
Answer C states: "IS-A relationships always require at least two class types"
=> Since as much as I am aware IS-A also applies to interfaces and not classes only, I think that should be somehow also part of the statement. At least on first interpret, I thought this answer is not correct, because of interfaces not mentioned. Later I figured the intention might have been to focus on "at least two" (i.e. one is not enough), but I still consider it capable of misinterpretation

[J Deckarm]

CD mock exams, objective 3, OCP Exam 1, question 4
answer B is marked as correct: "HAS-A relationships always rely on instance variables"
vs
CD mock exams, objective 3, OCP Exam 2, question 3
answer E is marked as incorrect: "HAS-A relationships are always defined with instance variables", and explanation says "class variables (statics) can also be used to define HAS-A relationships"

[Roel De Nijs]

J Deckarm wrote:chapter 10, page 571, answer 5
"Not shown is a class implementing class G that actually creates the object."
=> Should be likely "extending class G"

Added to the errata overview.

[Roel De Nijs]

J Deckarm wrote:CD mock exams, objective 3, OCP Exam 1, question 3
Answer C states: "IS-A relationships always require at least two class types"

Added to the errata overview.

[Roel De Nijs]

J Deckarm wrote:CD mock exams, objective 3, OCP Exam 1, question 4
answer B is marked as correct: "HAS-A relationships always rely on instance variables"

Added to the errata overview.

[J Deckarm]

chapter 7, page 395, table 7-3
"Java 7 with duplication" row "What happens if rain() adds a new checked exception?" case says to "Add another exception to the multi-catch block to handle the new exception."
=>
This seems to be incomplete, as in this case it seems that the newly added exception also has to be added to the throws clause of the ahhh() method. Or alternatively, it also seem to compile, if the newly added exception is not added to the multicatch, only to the throws clause of the ahhh() method.
Also "Java 6 style" seems to be incomplete, assuming the catch block for the newly added exception also contains a rethrow, i.e. catch (C e) { throw e; }, then C has to be also added to the throws clause of the ahhh() method
In general, the entire table seems to would worth reviewing and all possible cases described

[J Deckarm]

chapter 4, page 255
question 7 is related to enums, OCP objective 2.5, which is not listed beside the answer (it is mentioned at the question itself on page 252)

[Roel De Nijs]

J Deckarm wrote:chapter 7, page 395, table 7-3
"Java 7 with duplication" row "What happens if rain() adds a new checked exception?" case says to "Add another exception to the multi-catch block to handle the new exception."

Added to the errata overview.

J Deckarm wrote:In general, the entire table seems to would worth reviewing and all possible cases described

I did review the whole table and added the necessary changes to the errata overview. Here you'll find the code snippets of all possibilities

class A extends Exception {}
class B extends Exception {}
class C extends Exception {}
public void rain() throws A, B, C {}

// Java 6 style
public void ahhhWithRethrow() throws A, B, C {
    try {
        rain();
    } catch (A e) {
        throw e;
    } catch (B e) {
        throw e;
    } catch (C e) {
        throw e;
    }
}
public void ahhhNoRethrow() throws A, B {
    try {
        rain();
    } catch (A e) {
        throw e;
    } catch (B e) {
        throw e;
    } catch (C e) {
    }
}

// Java 7 with duplication
public void ahhhOnlyThrows() throws A, B, C {
    try {
        rain();
    } catch (A | B e) {
        throw e;
    }
}
public void ahhhCatchAndThrows() throws A, B, C {
    try {
        rain();
    } catch (A | B | C e) {
        throw e;
    }
}

// Java 7 without duplication
public void ahhh() throws A, B, C {
    try {
        rain();
    } catch (Exception e) {
        throw e;
    }
}

[Roel De Nijs]

J Deckarm wrote:chapter 4, page 255
question 7 is related to enums, OCP objective 2.5, which is not listed beside the answer (it is mentioned at the question itself on page 252)

Added to the errata overview.

[James Pittendreigh]

P881:

TYPE_SCROLL_SENSITIVE A cursor can be changed in the results...
should be
TYPE_SCROLL_SENSITIVE A cursor can be moved in the results...

[Roel De Nijs]

James Pittendreigh wrote:P881:

TYPE_SCROLL_SENSITIVE A cursor can be changed in the results...
should be
TYPE_SCROLL_SENSITIVE A cursor can be moved in the results...

Added to the errata overview.