Sybex CSG 17: Chapter 12 Modules: Error p. 703 Unnamed modules?

[Hans-Joachim Bleichenbacher]

In the section about unnamed modules, it is written that "Unnamed modules do not export any packages to named or automatic modules." Furthermore, the Table 12.17 specifies the unnamed modules as unreadable from automatic modules.

However in the Enthuware tests it says, that code in unnamed modules can be accessed from automatic modules. And also when I tried it out, code from an automatic module could successfully access the packages on the classpath (in an unnamed module).

Is this a mistake in the whole chapter?

br

[Mikalai Zaikin]

I think here is how it works:

- automatic module CAN access classes in unnamed module
The reason for that: an automatic module has no definition, so it automatically requires ALL modules (including the unnamed one)

- named module CANNOT access classes in unnamed module
The reason for that: a named module has no mechanism to "require" the unnamed module (right, since it has no name), so unnamed module classes are not recahable in the named module

P.S. note: there is just one unnamed module (or if saying more precisely one per classloader), so saying "unnamed modules" is not fully accurate

[Mikalai Zaikin]

Hans-Joachim Bleichenbacher wrote:In the section about unnamed modules, it is written that "Unnamed modules do not export any packages to named or automatic modules." Furthermore, the Table 12.17 specifies the unnamed modules as unreadable from automatic modules.

This part seems not right.

- The unnamed module exports all its packages.
- Classes in the unnamed module are only readable by other classes in the unnamed module AND from classes in automatic modules
- Named module cannot read the classes of the unnamed module (as it may not declare "requires" for the unnamed module in the module-info.java).

[Hans-Joachim Bleichenbacher]

Mikalai Zaikin wrote:

Hans-Joachim Bleichenbacher wrote:In the section about unnamed modules, it is written that "Unnamed modules do not export any packages to named or automatic modules." Furthermore, the Table 12.17 specifies the unnamed modules as unreadable from automatic modules.

This part seems not right.

- The unnamed module exports all its packages.
- Classes in the unnamed module are only readable by other classes in the unnamed module AND from classes in automatic modules
- Named module cannot read the classes of the unnamed module (as it may not declare "requires" for the unnamed module in the module-info.java).

Okay makes sense, thank you. So you would agree that there is a mistake in the book, right?

[Mikalai Zaikin]

Seems there is a mistake.

[Jeanne Boyarsky]

I think you are right. I'm going to take a few days to process my mental model of modules and then reply.

[Jeanne Boyarsky]

Ok. Now added to the errata. I also gave both of you a cow. This was wrong in the Java 11 book as well and nobody noticed.

I also fixed my mental model. I think the problem was that I didn't realize the automatic module is logically both on the module path (so named modules can access) and classpath (so can access the unnamed module.)

I was only thinking of it as used in the top down and bottom up migration examples where that doesn't happen.

[Marco Olivi]

Jeanne Boyarsky wrote:
I also fixed my mental model. I think the problem was that I didn't realize the automatic module is logically both on the module path (so named modules can access) and classpath (so can access the unnamed module.)

Does this make answer A correct for question 5?

5. A(n) _______________ module is on the classpath while a(n) ____________ module is on the module path. (Choose all that apply.)
A) automatic, named

[Hans-Joachim Bleichenbacher]

No, it does not. It is exactly the other way around. The book is perfectly correct about the names of modules. If a "module" does not contain a module-info.java file it can be either

an unnamed module if it is on the classpath

the automatic module if it is on the module path

E.g. if we have a foo.jar which does not contain a module-info.java file it can be either an unnamed or (part of) the automatic module, depending on if we specify it on the classpath or on the module path.

The point I was making is just about the code visibility/accessibility if you have both an unnamed module and an automatic module. From the automatic module you can then actually access code on the classpath (from the unnamed module).

[Marco Olivi]

Thank you Hans.
I'm sorry, but I'm still I bit confused about that topic.

the automatic module is logically both on the module path (so named modules can access) and classpath (so can access the unnamed module.)

If a jar file is both in the module and the class-path, shouldn't we consider them just like two different jar, first one as an automatic module and the second one as part of the unnamed-module?

I also tired to compile and run a class in an automatic-module, trying to read a class in a named-module. I was able to compile it with the option "--add-modules", but I wasn't able to run it.
javac -p mods automatic/package/MainClass.java --add-modules namedModule jar -cvf mods/moduleName.jar -C automatic/ . java -p mods -m moduleName/package.MainClass
The only way I found to make it work is to put the path of the named module in the classpath, but I think that in this way I am just making it an ununamed-module. Isn't it?
java -p mods -cp mods/namedModule.jar -m moduleName/package.MainClass

[Hans-Joachim Bleichenbacher]

Marco Olivi wrote:
If a jar file is both in the module and the class-path, shouldn't we consider them just like two different jar, first one as an automatic module and the second one as part of the unnamed-module?

As I understood, Jeanne did not mean that an automatic module is actually literally in the module and the classpath, but rather only logically/figuratively. Since it can access code specified either in the module path or the class path (@Jeanne correct me if I got this wrong). But in the actual command an automatic module is only specified on the module path.

I'm pretty sure that is how she meant it, as she also used the word logically.

Did that help a bit?

[Marco Olivi]

Thanks Hans, yes it helped, as I was misunderstanding Jeanne's sentence, and not just for the logically word. Reading again the whole topic made it clear.
Anyway I still don't understand why my MainClass does compile but does not execute..