Entry "1.5 Your first module" is misnumbered. It's not its own section, but a subsection of 1.4. Accordingly, subsections "The module system in action" and "Your non-modular project will be fine—mostly" also belong to 1.4 and sections 1.6/1.7 should be numbered 1.5/1.6.
This error is not confined to the table of contents - the sections themselves are also misnumbered (they line up with the table of contents). See "Chapter 1 - Sections 1.5 to 1.7, pages 21 to 30" for details.
Entry "6.3 Getting by without URLClassLoader" is misnumbered. It's not its own section, but a subsection of 6.2. Accordingly, the subsection "Finding troublesome casts" also belongs to 6.2 and sections 6.4/6.5/6.6 should be numbered 6.3/6.4/6.5.
This error only extends to the table of contents itself - the sections later in the book and all references to them are numbered correctly.
Starting with section 1.5 "Your first module", which should be subsection 1.4.2, these sections are misnumbered. This error is also present in the table of contents (see above), but references are correct in the sense that they refer to the intended section numbers. That means a textual reference to, for example, section 1.5 refers to "Goals of the module system", not "Your first module".
Here's the full list of intended/referenced vs printed section numbers:
|Your first module||1.4.2||1.5|
|The module system in action||1.4.3||1.5.1|
|Your non-modular project will be fine—mostly||1.4.4||1.5.2|
|Goals of the module system||1.5||1.6|
|Skills, old and new||1.6||1.7|
The paragraph starting with "Looks like" mentions a package
com.example.xml. That should be
The second bullet erroneously claims that there's a method
Module::getResource, which is not the case. The bullet should read:
A new class,
java.lang.Module, which we'll explore in depth in section 12.3.3 also has a method
getResourceAsStream. It behaves pretty much like the one on
The second bullet needs a "your:" "Start early by modularizing only your artifacts, possibly just a few at a time."
The module resolution process described in the section was implemented to prevent the default resolution of JEE modules for code on the class path. With their removal in Java 11, the mechanism became unnecessary and because of its complexity (an entire section including a figure) it was removed. On Java 11 and later the process is much simpler:
If the initial module is the unnamed module, all system modules (first and foremost, all java.* and jdk.* modules) and all modules on the upgrade module path that export at least one package without qualification become root modules.
The listing following "With that in our toolbox, the caller's module is at our fingertips" is almost indistinguishable from the same snippet on the preceding page. The line
return getCallerClass() should be annotated to point out that it changed.
The first bullet needs an additional "a": "It must be possible to spin up a fragment from a set of JARs at run time."
In the quote close to the bottom of the page, these terms should have been emphasized by being bold: "design", "carefully" (how ironic), "modularity", "API boundaries".