Errata Chapter 2 (Java OCA 8 Programmer I Study Guide, Sybex)

[Michel Parisien]

Time for my second contribution of errata, this time for chapter 2. My previous contribution for chapter 1 is here:

https://coderanch.com/t/659501/ocajp/certification/Errata-Chapter-Java-OCA-Programmer

All my preamble there applies here as well.

So without further ado:



Page 56, first paragraph after rule 4

"For the third rule, note that unary operators are excluded from this rule."

Not true. If they were, then System.out.println(-Byte.MIN_VALUE); would output -128, not 128 (which falls outside of the byte's range of -128..127).



Page 57, table 2.2, "+" and "-"

I would explain it differently, particularly the "+".

The "+" unary operator is actually almost a no-op. If the value is positive, it stays positive. If it is negative, it stays negative.

The "-" operator is a negator. It changes the sign. (Some exceptions exist, such as seen with System.out.println(-Integer.MIN_VALUE); and System.out.println(-Long.MIN_VALUE);)

These unary operators promote the type as would happen in a binary operation (as I mentioned in my previous errata point, unary operations are not exempt from this).

This example I think conveys the promotion concept well:

	public static void main(String[] args) {
		byte byteval = 0;
		short shortval = 0;
		int intval = 0;
		char charval = '\u0000';
		x(byteval); // byte
		x(shortval); // short
		x(intval); // int
		x(charval); // char
		x(+byteval); // int
		x(+shortval); // int
		x(+intval); // int
		x(+charval); // int
		byte otherbyteval = +byteval; // DOES NOT COMPILE
	}

	public static void x(byte a) {
		System.out.println("byte");
	}
	public static void x(short a) {
		System.out.println("short");
	}
	public static void x(int a) {
		System.out.println("int");
	}
	public static void x(char a) {
		System.out.println("char");
	}

Page 57, table 2.2, "!"

I would change the word "Boolean" in the "!" explanation to monospace formatting "boolean".



Page 61, sidebar

"so the system "wraps around" to the next lowest value and counts up from there."

For me, "next lowest value" would mean one higher than the lowest value.

Perhaps rephrase to "to the lowest value for that type".



Page 68, paragraph half way down the page

"The else operator takes a statement or block of statement"

should be "block of statements".



Page 75, middle of the page;
Page 75, source code at the bottom of the page;
Page 77, source code near the bottom of the page

Slight formatting issue with the line spacing of the first line.



Page 76, last paragraph of the switch statement

"In the fourth case statement, despite lastName being final, it is not constant as it is passed to the function; therefore, this line does not compile as well."

I feel this phrasing makes it sound like it being a parameter variable gives it a special behaviour. My suggested phrasing would be:

"In the fourth case statement, despite lastName being final, it cannot be evaluated to a constant value at compile time; therefore, this line does not compile as well."



Page 79, sidebar

"Any while loop can be converted to a do-while loop, and vice versa."

Not sure if I understand, or if the "vice versa" is well illustrated here.

Suppose we had this:

do {
	x--;
} while(x > 10);

How does this get converted into a while loop?

I mean I suppose if I had to, I could do this:

boolean keepLooping = true;
while (keepLooping) {
	x--;
	keepLooping = (x > 10);
}

Not sure if this was supposed to be mentioned, or if you didn't mean to say vice versa, or at least didn't mean it in that way. Anyway, thought I would mention it.



Page 82, section "3. Redeclaring a Variable in the Initializable Block"

The first code snippet of this section reads as follows:

int x = 0;
for (long y = 0, x = 4; x < 5 && y < 10; x++, y++) {   // DOES NOT COMPILE
  System.out.println(x + " ");
}

The second code snippet is this:

int x = 0;
long y = 10;
for(y = 0, x = 4; x < 5 && y < 10; x++, y++) {
  System.out.println(x + " ");
}

I would propose that the second line, "long y = 10;", should instead be "long y;", so that the intent of the first snippet is maintained (ie. it never intended to set y to 10).



Page 83, last paragraph

"The for-each loop declaration is composed of an initialization section and an object to be iterated over."

and further into the paragraph

"The left-hand side of the for-each loop must include a declaration for an instance of a variable"

So I would be inclined to agree more with the second part and say in the first part:

"The for-each loop declaration is composed of a variable declaration and an object to be iterated over."



Page 93, last paragraph, 2nd line

"flow control" should be "control flow".

[Jeanne Boyarsky]

Michel Parisien wrote:
Page 56, first paragraph after rule 4

"For the third rule, note that unary operators are excluded from this rule."

Not true. If they were, then System.out.println(-Byte.MIN_VALUE); would output -128, not 128 (which falls outside of the byte's range of -128..127).

That sentence doesn't say the rule is never true for unary operators. It does say that it isn't always true. Which is true short++ is not always promoted to int. Similarly, this code doesn't automatically promote to int:

byte b2 = -Byte.MAX_VALUE;

The case you mentioned isn't on the exam whereas calling ++ on a short is. So it is appropriate to only talk about this rule for binary operators in the book.

Michel Parisien wrote:
Page 57, table 2.2, "+" and "-"

I would explain it differently, particularly the "+".

The "+" unary operator is actually almost a no-op. If the value is positive, it stays positive. If it is negative, it stays negative.

The "-" operator is a negator. It changes the sign. (Some exceptions exist, such as seen with System.out.println(-Integer.MIN_VALUE); and System.out.println(-Long.MIN_VALUE);)

These unary operators promote the type as would happen in a binary operation (as I mentioned in my previous errata point, unary operations are not exempt from this).

Yet, it's not wrong the way it is in the book. So not an errata.

Michel Parisien wrote:
Page 57, table 2.2, "!"

I would change the word "Boolean" in the "!" explanation to monospace formatting "boolean".

Either way is right so not an errata.

Michel Parisien wrote:
Page 61, sidebar

"so the system "wraps around" to the next lowest value and counts up from there."

For me, "next lowest value" would mean one higher than the lowest value.

Agree that could be clearer. It's not an errata in that technically the next value is lowest.

Michel Parisien wrote:
Page 68, paragraph half way down the page

"The else operator takes a statement or block of statement"

should be "block of statements".

Agreed. Added this one to the errata. It's not page 69, not 68 though.

Michel Parisien wrote:
Page 75, middle of the page;
Page 75, source code at the bottom of the page;
Page 77, source code near the bottom of the page

Slight formatting issue with the line spacing of the first line.

Formatting isn't wrong. I don't see anything that's actually wrong there.

Michel Parisien wrote:
Page 76, last paragraph of the switch statement

"In the fourth case statement, despite lastName being final, it is not constant as it is passed to the function; therefore, this line does not compile as well."

I feel this phrasing makes it sound like it being a parameter variable gives it a special behaviour. My suggested phrasing would be:

"In the fourth case statement, despite lastName being final, it cannot be evaluated to a constant value at compile time; therefore, this line does not compile as well."

While rephrasing would be fine, it isn't incorrect as is. So not an errata.

Michel Parisien wrote:
Page 79, sidebar

"Any while loop can be converted to a do-while loop, and vice versa."

Not sure if I understand, or if the "vice versa" is well illustrated here.

It's a sidebar, not an exhaustive treatment. If you really didn't understand it, I'd say to start a new thread. But I think you are just asking to point out it could have been clearer.

Michel Parisien wrote:
Page 82, section "3. Redeclaring a Variable in the Initializable Block"

The first code snippet of this section reads as follows:

int x = 0;
for (long y = 0, x = 4; x < 5 && y < 10; x++, y++) {   // DOES NOT COMPILE
  System.out.println(x + " ");
}

The second code snippet is this:

int x = 0;
long y = 10;
for(y = 0, x = 4; x < 5 && y < 10; x++, y++) {
  System.out.println(x + " ");
}

I would propose that the second line, "long y = 10;", should instead be "long y;", so that the intent of the first snippet is maintained (ie. it never intended to set y to 10).

It's not wrong as is though so not an errata.

Michel Parisien wrote:
Page 83, last paragraph

"The for-each loop declaration is composed of an initialization section and an object to be iterated over."

and further into the paragraph

"The left-hand side of the for-each loop must include a declaration for an instance of a variable"

So I would be inclined to agree more with the second part and say in the first part:

"The for-each loop declaration is composed of a variable declaration and an object to be iterated over."

That would be clearer. It's not wrong as is though. Colloquial English and all.

Michel Parisien wrote:
Page 93, last paragraph, 2nd line

"flow control" should be "control flow".

No. We use the phrase "flow control" multiple times in the book including in a section header.

[Roel De Nijs]

Jeanne Boyarsky wrote:

Michel Parisien wrote:
Page 75, middle of the page;
Page 75, source code at the bottom of the page;
Page 77, source code near the bottom of the page

Slight formatting issue with the line spacing of the first line.

Formatting isn't wrong. I don't see anything that's actually wrong there.

I agree with the OP on this one (although it is a very tiny - almost minuscule - issue and a definite 100% nitpick )

If you closely look at the middle of page 75, at the output

Sunday
Weekday
Saturday

you'll notice that the line space between Sunday and Weekday is slightly greater than the one between Weekday and Saturday.

And the same remark applies to:

code snippet at bottom of page 75: getSortOrder method declaration

code snippet just beneath middle of page 77: roomInBelly variable declaration

In all other code snippets there's no such slightly greater line space between the 1st and 2nd line of a code snippet

[Michel Parisien]

Roel De Nijs wrote:I agree with the OP on this one (although it is a very tiny - almost minuscule - issue and a definite 100% nitpick )

I'm just going by, if I was inviting people to review something I did, I would find it tragic if they didn't tell me something because they were worried it would be perceived as a nitpick. Let reviewers maybe say too much, and then the author can disregard some of the comments as not a big deal, but it shouldn't be the reviewer who should keep some things that are more minor from the author.

(That sounded more serious than I intended. I know you were joking, and I went ahead and gave a serious answer

[Roel De Nijs]

Michel Parisien wrote:if I was inviting people to review something I did, I would find it tragic if they didn't tell me something because they were worried it would be perceived as a nitpick.

No worries! I already have some experience in reviewing certification study guides, so I'm pretty good at subdividing issues into categories like "must fix", "nitpick", "minor", and so on. A formatting issue (which these ones clearly are) is almost always nitpicking. And I would report them unless told otherwise

[Jeanne Boyarsky]

Michel: I'd certainly rather hear about more stuff than less. Although I'd rather hear about formatting over email rather than in a long list titled errata .

Roel: The reason I don't consider the formatting significant is because it doesn't make the code or result incorrect. It's also not something I can control as an author. There's also a distinction between a nitpick that is a minor thing that is wrong and a nitpick that is purely cosmetic. Since this one was just cosmetic, I was trying to reply that it isn't an errata.

[Michel Parisien]

Jeanne Boyarsky wrote:Michel: I'd certainly rather hear about more stuff than less. Although I'd rather hear about formatting over email rather than in a long list titled errata .

Roel: The reason I don't consider the formatting significant is because it doesn't make the code or result incorrect. It's also not something I can control as an author. There's also a distinction between a nitpick that is a minor thing that is wrong and a nitpick that is purely cosmetic. Since this one was just cosmetic, I was trying to reply that it isn't an errata.

Hi Jeanne,

I'll try to get better at understanding what an errata is as I progress. As far as I understand so far, they involve spelling and grammatical mistakes, and do not involve layout or rephrasings. Is that a fair assessment?

My review will continue in the month of February.

[Roel De Nijs]

Michel Parisien wrote:I'll try to get better at understanding what an errata is as I progress. As far as I understand so far, they involve spelling and grammatical mistakes, and do not involve layout or rephrasings. Is that a fair assessment?

Yes, it is! And of course technical errors (wrong class name, different output of a code snippet,...) as well

[Roel De Nijs]

Jeanne Boyarsky wrote:There's also a distinction between a nitpick that is a minor thing that is wrong and a nitpick that is purely cosmetic. Since this one was just cosmetic, I was trying to reply that it isn't an errata.

I knew this one was just a purely cosmetic nitpick and therefore isn't an errata item. But based on your response to the original errata item report ("I don't see anything that's actually wrong there."), I thought you didn't notice the slightly greater line space in the code snippets and that's what I tried to explain. But that was clearly a wrong assumption on my side.

[Jeanne Boyarsky]

Michel Parisien wrote:I'll try to get better at understanding what an errata is as I progress. As far as I understand so far, they involve spelling and grammatical mistakes, and do not involve layout or rephrasings. Is that a fair assessment?

Yeah. The only thing I'd clarify is if it is a rephrasing because the current phrasing is wrong, it is an errata. If it is a rephrasing because it could be clearer/better, it is not.

Roel De Nijs wrote:I knew this one was just a purely cosmetic nitpick and therefore isn't an errata item. But based on your response to the original errata item report ("I don't see anything that's actually wrong there."), I thought you didn't notice the slightly greater line space in the code snippets and that's what I tried to explain. But that was clearly a wrong assumption on my side.

That's because I don't view the formatting as wrong . So yes, it was about the definition of "wrong" .