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

[Michel Parisien]

Hello,

The following are the highlights of the errors I've found in chapter 1 of the book "OCA: Oracle Certified Associate Java SE 8 Programmer I Study Guide". I preferred offering up too much errata, so you might find a few of these to be picking at straws. That having been said, there are many additional notes I have taken but that do not qualify as errata. Instead they are additional tips I hope to pass on to a few of my friends who are more new to Java than me. If you wish, I could share that with you too if you think it might benefit the next edition of your book, but it probably doesn't belong in this errata thread.

So without further ado:

Page 8, exception at the bottom of the page

It reads:

        ZooException in thread "main"
java.lang.ArrayIndexOutOfBoundsException: 1
       at mainmethod.Zoo.main(Zoo.java:4)

But it should read:

Zoo
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 1
	at Zoo.main(Zoo.java:4)

(Technically Zoo can be found just about anywhere in this output, but this early in the book, explaining that might be heavy).

So the key differences are that I would recommend striking out "mainmethod." and changing the line number from 7 to 4.

Note that this change is the same as the first item listed here, but on a different page:

https://coderanch.com/t/656273/ocajp/certification/minor-typos-chapter-Java-OCA



Page 10, 2nd paragraph, 3rd line

"If it begins with java or javax, this means it came with the JDK."

This is not always true for javax. I could create the following for example:

package javax.x;

public class X {
	public static void main(String[] args) {

	}
}

This compiles and runs fine.

Here's a link that demonstrates plenty of regularly used code that is not, or at least did not start out as, included in Java, that start with javax:

http://mvnrepository.com/search?q=javax

My understanding of why most of these start with javax is because they are implementing a JSR before it is officially bundled with the JVM. Sometimes that can take years, but one can get early-access by incorporating a jar that has the code with the right package names and implementation.



Page 10, 2nd paragraph, 4th line

"From example" should be "For example".



Page 12, top half of the page

For the 6th import from the top, the comment reads:

NO GOOD - you cannot import methods only class names

But just to add clarity (as mentioned at the end of page 10), this should be:

NO GOOD - you cannot import methods in a regular (non-static) way, only class names. static imports are covered in chapter 4.

Your solution may be different, I am just trying to find a way to not have an unqualified blanket statement in this comment.



Page 12, at the bottom of the page

It reads:

import java.util.*;
import java.sql.*; // DOES NOT COMPILE

But it could use some clarification, like:

import java.util.*;
import java.sql.*; // DOES NOT COMPILE (not on this line, but on every reference of Date further down in the code)

or an even better solution might be to simply re-include the original code, and do this:

import java.util.*;
import java.sql.*;
public class Conflicts {
  Date date; // DOES NOT COMPILE
  // some more code
}

Page 18, in the section Instance Initializer Blocks

It reads:

"Anywhere you see braces is a code block".

This would include the braces in "class A {}" according to this phrasing, right?

Further down, it reads:

"Other times, code blocks appear outside a method. These are called instance initializers."

By this sentence, there is no room for the braces of "class A {}" being considered a code block, because class definition braces are certainly not instance initializers.

You can even go a bit further and say that you can have other blocks outside of a method, like static initializers, array initializers, etc.

So perhaps I would avoid saying that all blocks outside of a method are instance initializers.

And maybe clarify "code blocks" to say whether or not you even include class definition blocks, because you don't cover that in any of your examples.



Page 24, middle of the page

It reads:

"For example, the following statements assign these references to new objects:"

[...]

"Similarly, the greeting reference points to a new String object, "How are you?"."

Technically, there's some optimizations on Strings that are often made such that using the same literal twice will result in the same object on the heap.

Here's an example:

public class StringReferences {
	public static void main(String[] args) {
		String a = "hello";
		String b = "hello";
		String c = "he" + "l" + "l" + "o";
		String d = "l";
		String e = "he" + d + d + "o";
		System.out.println(a == b); //true
		System.out.println(a == c); //true
		System.out.println(a == e); //false
	}
}

So a bit of clarification language can leave the door open to this. For example, throwing in an "Assuming the string "How are you?" is never used anywhere else in the program, ...".

In my own copy of the book, I wrote next to the source listing for the string assignment: "Might reuse an existing string if the same literal is used elsewhere".



Page 30, top of the page

It reads:

Test.java:5: variable x might not have been initialized
		int reply = x + y;
		      ^

But it should say:

Test.java:7: error: variable x might not have been initialized
		int reply = x + y; // DOES NOT COMPILE
		            ^
1 error

page 30, bottom of the page

It reads:

"Class variables are shared across multiple objects."

Since this is pretty much the definition in the book for class variables, I wouldn't phrase it in quite that way. You can have zero instances and still have a class variable. The variable is more attached to a class metaobject that is accessible by objects of that class type (amongst others).



Page 31, end of second paragraph

It reads:

"and so wants the simplest type it can give the value"

The words are reversed. This should be:

"and so wants the simplest value it can give the type"



Page 31, table 1.2

I would prefer if, for float, it said the initialization value was 0.0f instead of 0.0, because the latter wouldn't compile in the case of an assignment.



Page 34, table 1.4

Perhaps not an errata, but more of a note: if this table were titled "Elements of a compilation unit", then it wouldn't be valid to say that a class declaration is required. However, it is titled "Elements of a class", and I suppose no declaration, no class. But it will compile. Just want to make sure that's clear.



Page 35, near the bottom just before the last code listing of the page

It reads:

"For example, these two classes must be in a file named Meerkat.java"

I would just add a slight clarification:

"For example, these two classes, if put together in a single file, must be put in a file named Meerkat.java".

[Roel De Nijs]

Hi Michel Parisien,

First of all, a warm welcome to CodeRanch!

Michel Parisien wrote:Page 8, exception at the bottom of the page

I agree about mainmethod but not about the line number as the code snippet itself does not define line numbers (although it's likely it's the same code snippet as on page 301). So mainmethod.Zoo.main should be Zoo.main (and line 7 might be line 4 in the stack trace).

Michel Parisien wrote:Page 10, 2nd paragraph, 3rd line

I agree with the book on this one. Although you can create your own classes in packages starting with java. and javax. you'll get a SecurityException (with a message similar to Prohibited package name: java.rdn) when you try to use one of these classes from another package. This code snippet will throw a SecurityException at runtime

package java.rdn;
public class X {}

package javax.rdn;
public class Y {
    public static void main(String[] args) {
        new java.rdn.X();
    }
}

Michel Parisien wrote:Page 10, 2nd paragraph, 4th line

That's indeed a minor typo!

Michel Parisien wrote:Page 12, top half of the page

I don't agree! With the import statement you can only import class names (or more in general: type names) but not methods. If you want to import members, you should use a static import (the import static statement).

Michel Parisien wrote:Page 12, at the bottom of the page

Agreed! As the compiler error is on the type of the reference variable date, the comment DOES NOT COMPILE should not be on the import statement.

Michel Parisien wrote:Page 18, in the section Instance Initializer Blocks

This section could indeed be clarified a bit.

Michel Parisien wrote:Page 24, middle of the page

At this point in the book, the String literal "How are you?" can definitely considered to be a new String object (the String Literal Pool is discussed on page 105). Based on the code snippets in this section it's clearly shown there's only one occurence of this String and thus a new String object will be created.

Michel Parisien wrote:Page 30, top of the page

Correct! The line number should be 7 instead of 5.

Michel Parisien wrote:page 30, bottom of the page

Although class variables can exist without any instances of that class, class variables are shared across multiple objects. So not an errata item.

Michel Parisien wrote:Page 31, end of second paragraph

Agreed! It should read "and so wants the simplest value it can give the type"

Michel Parisien wrote:Page 31, table 1.2

Although you need to use 0.0f to initialize a float primitive variable, I don't have a problem with the 0.0 value as default initialization value.

Michel Parisien wrote:Page 34, table 1.4

As you already stated, it's not an errata item. Without a class declaration you don't have a class. So to create a class, you need the class declaration. So the class declaration is the only required element of a class.

Michel Parisien wrote:Page 35

Based on the line numbers, it's obvious that both classes belong to the same source code file and therefore it's not necessary to mention it explicitly.

Hope it helps!
Kind regards,
Roel

[Jeanne Boyarsky]

Michel,
Welcome to CodeRanch!

Michel Parisien wrote:
Page 8, exception at the bottom of the page

I agree that mainmethod shouldn’t be there and added that to the errata. I also added the wrong line number. When I run the code, ZooException in thread "main" java.lang.ArrayIndexOutOfBoundsException: 1 is all on one line though so that probably depends.

Michel Parisien wrote:
Note that this change is the same as the first item listed here, but on a different page:

https://coderanch.com/t/656273/ocajp/certification/minor-typos-chapter-Java-OCA

It is the same! The Chapter 1 version was a preview.

Michel Parisien wrote:
Page 10, 2nd paragraph, 3rd line

"If it begins with java or javax, this means it came with the JDK."

First of all, it is true for the purposes of the exam. Plus readers should not be writing code in those packages. A lot of the packages you listed are provided as separate jars so you can compile without a container. Or as you noted were always intended for contribution to the JDK (or Java EE servers, but readers might not have heard of Java EE yet.) I’m sure there are some exceptions. Reality is a lot more complicated than an exam.

Michel Parisien wrote:
Page 10, 2nd paragraph, 4th line

"From example" should be "For example".

Noted on errata.

Michel Parisien wrote:
Page 12, top half of the page

No. Static imports aren’t covered until chapter 4 and it is good to avoid forward references in a book where they can be easily avoided. Also, there’s a balance between statements being 100% perfectly qualified and statements being clear. Plus there is context around it. We are discussing regular imports which strongly implies the statement is about regular imports.

As an aside, you sound like an experienced Java developer. Be careful on the OCA exam not to read into the questions.

Michel Parisien wrote:
Page 12, at the bottom of the page

Another reader noted this as well. I added it to our non-errata list. While technically the compiler error isn’t on the import line, it is in the file which is the point this example tries to make.

Michel Parisien wrote:
Page 18, in the section Instance Initializer Blocks

I agree it could be clearer and added it to my “for next time” list.

Michel Parisien wrote:
Page 24, middle of the page

String optimizations like that are outside the scope of the exam (and therefore book.)

Michel Parisien wrote:
Page 30, top of the page

Agreed. Added to errata.

Michel Parisien wrote:
page 30, bottom of the page

It doesn’t say that class variables require you to have an object. It says that if you have multiple objects, there is still only one class variable. Which is correct.

Michel Parisien wrote:
Page 31, end of second paragraph

Agreed and logged.

Michel Parisien wrote:
Page 31, table 1.2

I prefer the way it is. This isn’t an assignment. The point of the table is to remember that the default value is 0 (well 0.0) rather than syntax.

Michel Parisien wrote:
Page 34, table 1.4

Noted for consideration if we write an OCA 9 book.

Michel Parisien wrote:
Page 35, near the bottom just before the last code listing of the page

They are in a single file. That’s a case that we aren’t talking about here.

[Mushfiq Mammadov]

Jeanne Boyarsky wrote:

Michel Parisien wrote:
Page 8, exception at the bottom of the page

I agree that mainmethod shouldn’t be there and added that to the errata. I also added the wrong line number.

I also reported it in this post:
"mainmethod.Zoo.main should be Zoo.main in the exception text on page 8 too".
I didn't note line number because line number didn't start from line 1 and there were maybe empty lines in file.

Jeanne Boyarsky wrote:

Michel Parisien wrote:
Page 12, at the bottom of the page

Another reader noted this as well. I added it to our non-errata list. While technically the compiler error isn’t on the import line, it is in the file which is the point this example tries to make.

I guess this reader is me if I remember correctly

[Jeanne Boyarsky]

Mushfiq Mammadov wrote:I also reported it in this post

Yes. Michel actually linked to that in his post. The trick is that the error existed in both chapters 1 and 6. You reported in chapter 6. Michel noticed it was in chapter 1 as well.

Mushfiq Mammadov wrote:
I guess this reader is me if I remember correctly

Yup!

[Jeanne Boyarsky]

I stand corrected. Mushfiq did notice it in both places. I didn't noticed he noticed.

[Tom Shinkelstein]

Hi, I found this question confusing - end of chapter 1, question 5:

Given the following classes, which of the following can independently replace INSERT IMPORTS HERE to make the code compile? (Choose all that apply)
package aquarium;
public class Tank { }
package aquarium.jellies;
public class Jelly { }
package visitor;
INSERT IMPORTS HERE
public class AquariumVisitor {  public void admire(Jelly jelly) { } }

I'm viewing this in Safari Online so not sure if the online version is causing some loss of graphics (maybe separators before package statements?). Surely one file with all the above will not compile (for starters you can only have one public class in a file).
Does the print version look different?  Have attached a screenshot.

[Jeanne Boyarsky]

Tom,
Welcome to CodeRanch!

Egads! That looks horrible in your screenshot. In the printed book, there is a blank line before "package aquarium.jellies;" and another blank line before "package visitor'"

So yes, please pretend they are in three separate files.

[Tom Shinkelstein]

Thanks for confirming that Jeanne!

[Tom Shinkelstein]

in chapter 2 you have:
2: Adding Multiple Terms to the for Statement - see attachment.  You state that is will print 0,1,2,3,4.  However it will also print 5.

[Tom Shinkelstein]

in the attached screenshot you state that "The variables in the initialization block must all be of the same type", however as per your previous example you can have incompatible data types in the initialization block, however if any declarations are present then they have to be of the same type.

[Jeanne Boyarsky]

Tom Shinkelstein wrote:in chapter 2 you have:
2: Adding Multiple Terms to the for Statement - see attachment.  You state that is will print 0,1,2,3,4.  However it will also print 5.

Yes. That's already in the errata under page 82 (using printed book numbers; I don't know if your e-book uses the same numbers).

Tom Shinkelstein wrote:in the attached screenshot you state that "The variables in the initialization block must all be of the same type", however as per your previous example you can have incompatible data types in the initialization block, however if any declarations are present then they have to be of the same type.

IT's not an errata per se because we are referring to the declaration in tha particular initialization block. I do agree it could be clearer. So cow to you for pointing it out and I've noted it in our private list.

[Tom Shinkelstein]

Ok, thanks for confirming those Jeanne.  Unfortunately I don't have page numbers, but I'll try and match with existing errors first if I find any more.

[Tom Shinkelstein]

In chapter 3 is states " As you learned in Chapter 1, the default value of an int is 0."  

Surely that only applies to non-local variables as local variables need to be explicitly initialized?

Would it be better to say that " As you learned in Chapter 1, the default value of an int is 0 for non-local variables but needs to be explicitly initialized if it is a local variable.  However, for an array of ints, the array elements are always initialized to 0 regardless of whether or not the array is a local variable. "?

[Jeanne Boyarsky]

Tom,
It's ok. I understand the page numbers are different. I'd rather you post if you aren't sure.

Re chapter 3, the context of that sentence is "if a default value is needed".

[Tom Shinkelstein]

In Appendix A, for question 26 you have "The code does not compile" - I think you meant "The code does compile"?

[Jeanne Boyarsky]

Tom Shinkelstein wrote:In Appendix A, for question 26 you have "The code does not compile" - I think you meant "The code does compile"?

Which chapter? Appendix A has the answers for all the chapters.

[Tom Shinkelstein]

This in Chapter 3, however, my apologies, I see you already have that in the official errata.

[Tom Shinkelstein]

In chapter 5, page 243, it states "If the parent doesn't have a no-argument constructor and the child doesn't define any constructors, the compiler will throw an error and try to insert a default no-argument constructor into the child class."  In this case the compiler will create default constructors in both cases, with a call to super() in the child constructor.  That call will result in a call to the default constructor in the super class, hence no compilation error.

Example below, Mammal doesn't have a no-argument constructor and child Elephant doesn't define any constructors.  This compiles without a problem.

public class Mammal {
    public static void main(String[] args) {
        Elephant e1 = new Elephant();
        System.out.println(e1.a);
    }
}

public class Elephant extends Mammal{
    int a = 5;
}

[Tom Shinkelstein]

In chapter 5, page 243, it states "5. If the parent doesn't have a no-argument constructor, the compiler requires an explicit call to a parent constructor in each child constructor." Two cases: (A) If the parent doesn't have a no-argument constructor (and doesn't have any other constructors defined) and child constructors exist then those child constructors have an implicit call to the default constructor in the super class and hence won't need any explicit call.  (B) In the case where the parent doesn't have a no-argument constructor because it defines constructors with arguments but does not explicitly define a no-argument constructor, then, yes, I would agree that the child constructors will need an explicit call to one of the parent constructors.

I think you were trying to say that "If the parent doesn't have a no-argument constructor because constructors with arguments have been defined in the parent (and none without arguments), the compiler requires an explicit call to a parent constructor in each child constructor" but what what you have written could be misinterpreted as Case A, which doesn't require explicit calls to constructors in the parent.  Similar logic also applies to my previous post about (4) on the same page.

Case A:  the parent doesn't have a no-argument constructor (and doesn't have any other constructors defined) and child constructors exist then those child constructors have an implicit call to the default constructor in the super class and hence won't need any explicit call.  No compilation error.

public class Mammal {
    public static void main(String[] args) {
        Elephant e1 = new Elephant();
        System.out.println(e1.a);
    }
}
public class Elephant extends Mammal{
    int a;
    public Elephant() {
         a = 5;
    }
}