Errata for The Java Module System

Thank you for purchasing The Java Module System. We gave it our best to create a perfect book and yet some errors slipped by. We'll report them here and update this list as necessary. If you find an error not listed here, report it on liveBook. Thank you!

Last update: June 9, 2019

Table of contents

On page viii

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.

On page x

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.

Chapter 1

Sections 1.5 to 1.7, pages 21 to 30

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:

Section namereferencedprinted
Your first module1.4.21.5
The module system in action1.
Your non-modular project will be fine—mostly1.
Goals of the module system1.51.6
Skills, old and new1.61.7

In section 1.5, page 21

The paragraph starting with "Looks like" mentions a package com.example.xml. That should be my.xaml.api instead.

Chapter 5

In section 5.2.2, page 109

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 Class.

Chapter 8

In the introduction, page 167

The second bullet needs a "your:" "Start early by modularizing only your artifacts, possibly just a few at a time."

In section 8.2.2, page 173

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.

Chapter 12

In section 12.4.2, page 293

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.

In section 12.4.3, page 294

The first bullet needs an additional "a": "It must be possible to spin up a fragment from a set of JARs at run time."

Chapter 15

In section 15.3.3, page 361

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".