Some potential Errata (Java OCA 8 Programmer I Study Guide, Sybex)

[Jan Stückrath]

I have now finished reading the book and wanted to mention a few (maybe) errata-worthy pages.
Page 71:
The first code snippet seems to have a stray "final". Normally this should not be a problem, but the "equivalent ternary operator code snippet" below has no final, which makes it not really equivalent, right?
Page 179:
Last sentence of the paragraph after the big code snippet: "We are not allowed to refer to members of the Bird class since we are not in the same package and Bird is not a subclass of Bird." Did you mean "Bird is not a subclass of Goose"?
Page 249:
First sentence of last paragraph: "Any time you see a method that appears to be overridden on the example [...]". It should be "on the exam", right?

I also have some Errata for the Errata.
There are wrong page numbers for two Errata items. One entry for chapter 4 says "page 11", but should be 191 (it is sorted between items for page 188 and 191). And the very last entry (for question #9 of Chapter 6 mock explanation) says "page 328" instead of 350.

[Roel De Nijs]

Jan Stückrath wrote:Page 71:
The first code snippet seems to have a stray "final". Normally this should not be a problem, but the "equivalent ternary operator code snippet" below has no final, which makes it not really equivalent, right?

Both code snippets are about the assignment of a value to variable x depending on a condition. So from this point of view both code snippets are equivalent. But of course in the first code snippet you can't reassign a value to variable x as it's marked final while you can in the second code snippet.

Jan Stückrath wrote:Page 179:
Last sentence of the paragraph after the big code snippet: "We are not allowed to refer to members of the Bird class since we are not in the same package and Bird is not a subclass of Bird." Did you mean "Bird is not a subclass of Goose"?

I think it should indeed be "Bird is not a subclass of Goose". We can quickly illustrate this with a code snippet, similar to the one in the book (but more concise)

package bird;
import goose.Goose;
import wildgoose.WildGoose;
public class Bird {
    protected String text = "abc";

    public void method1() {
        Bird other = new WildGoose();
        System.out.println(other.text); // ok - same class
    }

    public void method2() {
        Goose other = new WildGoose();
        System.out.println(other.text); // ok - subclass
    }

    public void method3() {
        WildGoose other = new WildGoose();
        System.out.println(other.text); // ok - subclass
    }
}

package goose;
import bird.Bird;
import wildgoose.WildGoose;
public class Goose extends Bird {
    public void method1() {
        Bird other = new WildGoose();
        //System.out.println(other.text); // compiler error
    }

    public void method2() {
        Goose other = new WildGoose();
        System.out.println(other.text); // ok - same class
    }

    public void method3() {
        WildGoose other = new WildGoose();
        System.out.println(other.text); // ok - subclass
    }
}

package wildgoose;
import bird.Bird;
import goose.Goose;
public class WildGoose extends Goose {
    public void method1() {
        Bird other = new WildGoose();
        //System.out.println(other.text); // compiler error
    }

    public void method2() {
        Goose other = new WildGoose();
        //System.out.println(other.text); // compiler error
    }

    public void method3() {
        WildGoose other = new WildGoose();
        System.out.println(other.text); // ok - same class
    }
}

Jan Stückrath wrote:Page 249:
First sentence of last paragraph: "Any time you see a method that appears to be overridden on the example [...]". It should be "on the exam", right?

Yes, it is!

Jan Stückrath wrote:One entry for chapter 4 says "page 11", but should be 191 (it is sorted between items for page 188 and 191).

Correct!

Jan Stückrath wrote:And the very last entry (for question #9 of Chapter 6 mock explanation) says "page 328" instead of 350.

True!

Hope it helps!
Kind regards,
Roel

[Jeanne Boyarsky]

Confirmed and logged all. Can you confirm I didn't manage to mess up the copy/pasting of the accent mark in your name?

[Jan Stückrath]

Roel De Nijs wrote:
I think it should indeed be "Bird is not a subclass of Goose". We can quickly illustrate this with a code snippet, similar to the one in the book (but more concise)

Thank you, I also created a similar example to test this behaviour myself. I noticed that protected access is really tricky and gets even trickier when applied to methods. For instance let me modify your Bird and Goose classes as follows (WildGoose remains unchanged):

package bird;
import goose.Goose;
import wildgoose.WildGoose;
public class Bird {
    protected String text = "abc";
    
    protected String getText() {
    	return text;
    }
 
    public void method1() {
        Bird other = new WildGoose();
        System.out.println(other.text); // ok - same class
        System.out.println(other.getText()); // ok - same class
    }
 
    public void method2() {
        Goose other = new WildGoose();
        System.out.println(other.text); // ok - subclass
        //System.out.println(other.getText()); // will not compile
        System.out.println(((Bird)other).getText()); // but this is fine
    }
 
    public void method3() {
        WildGoose other = new WildGoose();
        System.out.println(other.text); // ok - subclass
        //System.out.println(other.getText()); // will not compile
        System.out.println(((Bird)other).getText()); // but this is fine
    }
}

package goose;
import bird.Bird;
import wildgoose.WildGoose;
public class Goose extends Bird {
    public void method1() {
        Bird other = new WildGoose();
        //System.out.println(other.text); // compiler error
        //System.out.println(other.getText()); // compiler error
    }
 
    public void method2() {
        Goose other = new WildGoose();
        System.out.println(other.text); // ok - same class
        System.out.println(other.getText()); // ok - same class
    }
 
    public void method3() {
        WildGoose other = new WildGoose();
        System.out.println(other.text); // ok - subclass
        System.out.println(other.getText()); // ok - subclass
    }
    
    @Override
    protected String getText() {
    	return super.getText();
    }
}

Lines 20 and 27 of the Bild class will not compile, triggered by the getText() method being overwritten in Goose. However, the casts in lines 21 and 28, which will always work, compile. Note that this problem does not occur if the subclass does not override the method, as can be seen in Line 20 of Goose (WildGoose does not override getText()). But this means that if we access a proteced method of another object of a derived class in the superclass using a non-superclass reference type, a change in the subclass can cause the superclass to not compile!
Although this behaviour makes sense if we think about how protected is meant to be used, I find it counterintuitive on first glance.

Jeanne Boyarsky wrote:Can you confirm I didn't manage to mess up the copy/pasting of the accent mark in your name?

Yes, everything is correct. Thank you.

[Roel De Nijs]

Jan Stückrath wrote:Lines 20 and 27 of the Bird class will not compile, triggered by the getText() method being overwritten in Goose. However, the casts in lines 21 and 28, which will always work, compile. Note that this problem does not occur if the subclass does not override the method, as can be seen in Line 20 of Goose (WildGoose does not override getText()). But this means that if we access a proteced method of another object of a derived class in the superclass using a non-superclass reference type, a change in the subclass can cause the superclass to not compile!
Although this behaviour makes sense if we think about how protected is meant to be used, I find it counterintuitive on first glance.

That's an awesome observation. Have a cow!

If we look at the second bullet point at the top of page 179, we read

Java OCA 8 Programmer I Study Guide, Sybex wrote:A member is used through a variable. This is the case on lines 10, 11, 15, and 16. In this case, the rules for the reference type of the variable are what matter. If it is a subclass, protected access is allowed. This works for references to the same class or a subclass.

In your example we notice that both Bird and Goose classes define a protected getText() method. On lines 20 and 27 of the Bird class we try to access a member using a variable so the second bullet point definitely applies to these lines of code. According to this bullet point, protected access is allowed for references to the same class or a subclass. But the code snippet clearly illustrates that this statement is not 100% accurate and something is missing. On line 20 the type of the reference is Goose (same class as the protected method) and on line 27 the reference type is WildGoose (which is a subclass), so according to the second bullet protected access should be allowed but it isn't...

[Ramya R Subramanian]

Sorry about digging out the old thread.But I noticed a few things.Roel, In your 2nd post of the thread..

In Goose Class method2(), shouldnt this be ok-subclass . There is no "text" in the Goose class. And "other" is able to access "text" because it inherits it from Bird.

In WildGoose method3(), shouldnt this be ok-subclass. Goose inherits "text" from Bird. And since WildGoose extends Goose it inherits "text" as well. there is no "text" in WildGoose.
And in your last post

Roel De Nijs wrote:On line 20 the type of the reference is Goose (same class as the protected method) and on line 27 the reference type is WildGoose (which is a subclass), so according to the second bullet protected access should be allowed but it isn't...

The line 20 is in the Bird Class and the reference is Goose .Goose is a different class and not the same as the protected method. and when you cast it to the same class as the protected method(Bird), it works fine.
(my understanding) Line 27 doesnt compile because, though "other" is a subclass reference(of WildGoose). But it is in a different class(Bird). And so access is not permitted.
from JLS

Let C be the class in which a protected member is declared. Access is permitted only within the body of a subclass S of C.

Please do correct me, If I have misunderstood something.

[Roel De Nijs]

Ramya Subraamanian wrote:In Goose Class method2(), shouldnt this be ok-subclass . There is no "text" in the Goose class. And "other" is able to access "text" because it inherits it from Bird.

In WildGoose method3(), shouldnt this be ok-subclass. Goose inherits "text" from Bird. And since WildGoose extends Goose it inherits "text" as well. there is no "text" in WildGoose.

No! "same class" refers to the type of the reference variable, not to which instance variable text is used. So for example in method2() of class Goose, the type of the reference (local) variable is Goose => "ok - same class". (Instance variable text will indeed be inherited from superclass Bird).

The line 20 is in the Bird Class and the reference is Goose .Goose is a different class and not the same as the protected method. and when you cast it to the same class as the protected method(Bird), it works fine.
(my understanding) Line 27 doesnt compile because, though "other" is a subclass reference(of WildGoose). But it is in a different class(Bird). And so access is not permitted.

There is also a protected method getText() defined in the Goose class. On line 20 the reference variable is of type Goose, so it's the same as the class which defines the protected method. You are correct about casting the reference variable to Bird (as illustrated on line21 and line28). But the only reason why this compiles, is because class Bird defines a getText() method as well, which happens to be protected. But the access modifier is irrelevant in this case, because the reference variable is the same as the class defining both methods. So even if the getText() method in class Bird would have been private, both lines (line21 and line28) will compile too.

Hope it helps!
Kind regards,
Roel

[Ramya R Subramanian]

same class" refers to the type of the reference variable, not to which instance variable text is used. So for example in method2() of class Goose, the type of the reference (local) variable is Goose => "ok - same class"

okay, thank you. understood it now.

There is also a protected method getText() defined in the Goose class. On line 20 the reference variable is of type Goose, so it's the same as the class which defines the protected method

But that overridden getText() will not be visible at all from another class(Bird), because it is protected and in another package.I thought "same class" meant the Bird class.But Yes, it would compile even if getText() were private. And also thought that "references to the same class ..." in the book meant the references to classes like the Swan class or its subclasses.