Tobias Zeiler

Mike is right. I got lost in scopes.

On page 216 is the Review Question 19 of Chapter 4:

19. Which of the following fill in the blank to print a positive integer? (Choose all that apply.)
String[] s1 = { "Camel", "Peacock", "Llama"}; String[] s2 = { "Camel", "Llama", "Peacock"}; String[] s3 = { "Camel"}; String[] s4 = { "Camel", null}; System.out.println(Arrays. ________________________);

These are the answer possibilities:

A. compare(s1, s2)
B. mismatch(s1, s2)
C. compare(s3, s4)
D. mismatch (s3, s4)
E. compare(s4, s4)
F. mismatch (s4, s4)

On page 923 is the answer to the question:

19.    A, B, D.    The compare() method returns a positive integer when the arrays are different and the first is larger. This is the case for option A since the element at index 1 comes first alphabetically. It is not the case for option C because the s4 is longer or for option E because the arrays are the same.
The mismatch() method returns a positive integer when the arrays are different in a position index 1 or greater. This is the case for options B and D since the difference is at index 1. It is not the case for option F because there is no difference.

The following sentence from the answer may contain an erratum:

This is the case for option A since the element at index 1 comes first alphabetically.

A letter counts as larger if it is alphabetically second, not first. So "Peacock," the second element of the s1 array, has its first letter alphabetically after "Llama," the second element of the s2 array. This results in s1 being larger and answer option A being one of the correct answers.
The sentence could be changed as follows:

This is the case for option A since the element at index 1 comes second alphabetically for the first array s1, making s1 larger.

On page 214 is the Review Question 15 of Chapter 4:

15. What is the output of the following? (Choose all that apply.)
var arr = new String[] { "PIG", "pig", "123"}; Arrays.sort(arr); System.out.println(Arrays.toString(arr)); System.out.println(Arrays.binarySearch(arr, "Pippa"));

These are the answer possibilities from page 215:

A. [pig, PIG, 123]
B. [PIG, pig, 123]
C. [123, PIG, pig]
D. [123, pig, PIG]
E. -3
F. -2
G. The results of binarySearch() are undefined in this example.

On page 923 is the answer:

15. C, E. Numbers sort before letters and uppercase sorts before lowercase. This makes option C one of the answers. The binarySearch() method looks at where a value would be inserted, which is before the second element for Pippa. It then negates it and subtracts one, which is option E.

The answer options C and E are correct. However, there may be an erratum in the explanation for option E:

The binarySearch() method looks at where a value would be inserted, which is before the second element for Pippa.

Pippa   counts as larger than   PIG   because its second letter is lowercase, making the letter and the entire string   Pippa   larger compared to  PIG  .
The sentence should therefore read:

The binarySearch() method looks at where a value would be inserted, which is after the second element for Pippa.

Also, the calculation to get -3 would not work. If   Pippa   was inserted as the second element, the binarySearch() method would return -2.

On page 144 is the Review Question 8 of Chapter 3:

8. What is the output of calling printType(11)?
void printType(Object o) {     if(o instanceof Integer bat) {          System.out.print("int");     } else if(o instanceof Integer bat && bat < 10) {          System.out.print("small int");     } else if(o instanceof Long bat || bat <= 20) {          System.out.print("long");     } default {          System.out.print("unknown");     } }

The answer possibilities are:

A. int
B. small int
C. long
D. unknown
E. Nothing is printed.
F. The code contains one line that does not compile.
G. The code contains two lines that do not compile.
H. None of the above

On page 917 follows the answer to the question:

8.   G.  The first two pattern matching statements compile without issue. The variable bat is allowed to be used again, provided it is no longer in scope. Line 36 does not compile, though. Due to flow scoping, if s is not a Long, then bat is not in scope in the expression at <= 20. Line 38 also does not compile as default cannot be used as part of an if/else statement. For these two reasons, option G is correct.

In this last part there could be an erratum in the following sentence:

The variable bat is allowed to be used again, provided it is no longer in scope.

The variable bat can only be reused if it is still in scope, so this sentence should be changed to:

The variable bat is allowed to be used again, provided it is still in scope.

Of course, I looked for us Locale variables before opening the topic. But there is none that could be used. A few pages before page 639, two unrelated  us  NumberFormat variables are used. On the next pages (640 and 641), two  us  Locales are actually declared. But they are declared later and are already in another chapter.

Thanks for the feedback. I updated the code example and deleted the misleading sentence. There is no  us  variable declared.

On page 791 is the FIGURE 14.3 "I/O and NIO.2 class and interface relationships" printed. It is attached below the text.

The arrow between Path and java.net.URI only points from Path to java.netURI. But it should logically point in both directions, since conversion is possible in both directions, for example with Path.of(URI) and Path.toUri(). In addition, the arrow between Path and java.io.file in the figure points in both directions.

On page 693 is the following paragraph:

Describing with jar
Like the java command, the jar command can describe a module. These commands are equivalent:
jar -f mods/zoo.animal.feeding.jar -d
jar --file mods/zoo.animal.feeding.jar --describe-module
The output is slightly different from when we used the java command to describe the module. With jar, it outputs the following:
zoo.animal.feeding jar:file:///absolutePath/mods/zoo.animal.feeding.jar
/!module-info.class
exports zoo.animal.feeding
requires java.base mandated

So in the book’s output the front slash / is placed before the exclamation mark:

/!module-info.class

This must be a typo, as the exclamation mark is there to separate the path to the JAR file from the specific resource of the JAR file. So when I ran the jar commands, the two signs were swapped:

zoo.animal.feeding jar:file:///absolutePath/mods/zoo.animal.feeding.jar!/module-info.class

On page 639 is the following paragraph:

For the exam, you do not need to memorize the various display and formatting options for each category. You just need to know that you can set parts of the locale independently. You should also know that calling Locale.setDefault(us) after the previous code snippet will change both locale categories to en_US.

Locale.setDefault(Locale.US) should be used instead of Locale.setDefault(us) because the previous code example, shown in full below, does not declare a Locale variable us.
public static void printCurrency(Locale locale, double money) {     System.out.println(          NumberFormat.getCurrencyInstance().format(money)          + ", " + locale.getDisplayLanguage()); } public static void main(String[] args) {     var spain = new Locale("es", "ES");     var money = 1.23;     // Print with default locale     Locale.setDefault(new Locale("en", "US"));     printCurrency(spain, money); // $1.23, Spanish     // Print with selected locale display     Locale.setDefault(Category.DISPLAY, spain);     printCurrency(spain, money); // $1.23, español     // Print with selected locale format     Locale.setDefault(Category.FORMAT, spain);     printCurrency(spain, money); // 1,23 €, español }

OK, I'll give it a try  

There should be a Foo.class and a Baa.class file. I suspect Baa is not a nested class, so it should not be Foo$Baa.class.

The entire relevant paragraph on page 492 reads:

You can also sort objects that you create yourself. Java provides an interface called Comparable. If your class implements Comparable, it can be used in data structures that require comparison. There is also a class called Comparator, which is used to specify that you want to use a different order than the object itself provides.

Comparable is correctly called an interface, so I think it would be helpful to do the same for Comparator to avoid confusion.

On page 597 is the following paragraph:

The exam might also try to trick you. Do you see why this code doesn’t compile?
throw RuntimeException(); // DOES NOT COMPILE
If your answer is that there is a missing keyword, you’re absolutely right. The exception is
never instantiated with the new keyword.

The last sentence should read:

The exception is never instantiated without the new keyword.

The Comparator<T> interface is introduced as a class on page 492, quote:

There is also a class called Comparator, which is used to specify that you want to use a different order than the object itself provides.

But it is an interface, see:
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Comparator.html

Table 9.9 on page 491 lists some collections from ArrayDeque to TreeSet and their attributes, such as whether they are sorted or not. I have uploaded a screenshot of the table in the attachments.

The second sentence below the table simply states that null values are not allowed in sorted data structures:

The data structures that involve sorting do not allow null values.

But the unsorted ArrayDeque listed in the first row of Table 9.9 also does not allow null elements. See the Java 17 documentation for ArrayDeque, fourth sentence in the first paragraph:
"Null elements are prohibited."
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ArrayDeque.html

The following infobox is printed on page 384:

Creating .class Files for Inner Classes
Compiling the Home.java class with which we have been working creates two class files. You should be expecting the Home.class file. For the inner class, the compiler creates Home$Room.class. You don’t need to know this syntax for the exam. We mention it so that you aren’t surprised to see files with $ appearing in your directories. You do need to understand that multiple class files are created from a single .java file.

I would suggest changing the title as follows:

Creating .class Files for Nested Classes

Separate .class files are not only created for inner classes, but also for static nested classes and local classes.

The content on page 388 is part of the section on local classes, but the infobox on the same page reiterates page 384 that separate .class files are generated (only) for inner classes. See the first sentence in the infobox:

Why Can Local Classes Only Access final or Effectively Final Variables?
Earlier, we mentioned that the compiler generates a separate .class file for each inner class. A separate class has no way to refer to a local variable. However, if the local variable is final or effectively final, Java can handle it by passing a copy of the value or reference variable to the constructor of the local class. If it weren’t final or effectively final, these tricks wouldn’t work because the value could change after the copy was made.

This again leaves the question open what would happen in case of static nested classes and local classes. Therefore, the first sentence should be changed to:

Earlier, we mentioned that the compiler generates a separate .class file for each nested class.