Automatic modules can read the unnamed module, so their dependencies can go onto the class path. (link)
Any class that is not on the module path is part of an unnamed module. Technically, there may be more than one unnamed module, but all of them together act as if they are a single module which is called the unnamed module. As with automatic modules, the unnamed module can access all other modules, and all of its packages are exported and opened. (link)
Recall from Chapter 5 of Volume I that JAR files can contain, in addition to class files and a manifest, file resources which can be loaded with the method Class.getResourceAsStream, and now also with Module.getResourceAsStream (link)
Open modules combine the compile-time safety of the module system with the classic permissive runtime behavior. (link)
Using the opens keyword, a module can open a package, which enables reflective access to all instances of classes in the given package. (link)
If you want to load a module into JShell, include the JAR on the module path and use the --add-modules option: (link)
Instead, a module can be deployed by placing all its classes in a JAR file, with a module-info.class in the root. Such a JAR file is called a modular JAR. (link)
Module names are only used in module declarations (link)
A module can make classes and packages selectively available so that its evolution can be controlled. (link)
The Instant class is a close analog to java.util.Date. In Java 8, that class has two added methods: the toInstant method that converts a Date to an Instant, and the static from method that converts in the other direction. (link)
The third time is a charm, and the java.time API introduced in Java 8 has remedied the flaws of the past and should serve us for quite some time. (link)