How can unnamed modules access JAR files on the module path?

[Edmund Yong]

I have a class B that uses class A. They are in b.jar and a.jar respectively. In a bottom-up strategy to migrate to a modular system, I first migrated a.jar. Now a.jar has a module-info.class and it exports its package. I put a.jar in a module path "mod". The class A also has a main() method, so I tested it successfully as:

java -p mod -m com.test.a/com.test.a.A

Now b.jar is still on the classpath, and so it is an unnamed module. According to the book OCP 11 by Jeanne and Scott, page 323: "The unnamed modules are on the classpath. They can access JAR files on both the classpath and the module path.". To test this statement, I run B as follows:

java -p mod -cp b.jar com.test.b.B

Exception in thread "main" java.lang.NoClassDefFoundError: com/test/a/A
        at com.test.b.B.main(B.java:9)
Caused by: java.lang.ClassNotFoundException: com.test.a.A
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
        ... 1 more

So the statement about the unnamed module being able to access JAR files on the module path is not true. Or have I misunderstood the statement?

[Stephan van Hulst]

I'm unpracticed with modules, but I *think* what's happening is that you're getting confused between "observable" modules and "readable" modules.

Observable modules are those that the compiler or JVM knows that are going to be used, so it loads them up. If you declare the location of your module folder, it does not mean that all modules in it are automatically loaded. Java starts by loading the module that you want to execute, and a couple of default modules that are part of the standard API. From there, it looks at their module descriptors and loads all modules that they require recursively. You are executing a class from the unnamed module though, and the unnamed module doesn't have explicit dependencies.

So just because the unnamed module is allowed to read your named module (readability), doesn't mean that your named module is also automatically loaded (observability).

Try running your command again, but now also use the --add-modules command line option to tell the JVM to load your named module.

Note that you can easily tell the difference between observability and readability issues from the error message. When Java complains that it can't find a certain class, it means it didn't load the module that the class is in. If a module tries to access another module that isn't an explicit or transitive dependency, Java will say something along the lines of "package P is declared in module A but module B doesn't read it".

[Stephan van Hulst]

You can test my theory above by making another module S that has an explicit dependency on your module A and contains a main method that does nothing else but call the main method of your B class in the unnamed module. Then tell Java to execute module S (without using the --add-modules option).

What happens now is Java loads up modules S, A and the unnamed module (A because it is an explicit dependency of S and the unnamed module because it is always loaded). The main method in your B class (that is called through S) is also allowed to access the A module, because the unnamed module implicitly requires ALL loaded modules. This is what the book is talking about: The unnamed module on the class path can access all loaded JARs on both the class path and module path.

[Edmund Yong]

I honestly don't understand what you're talking about. Is there really such a concept as "observable" modules and "readable" modules, or is it something that you *thought* it is? The book could have been clearer with some examples, instead of just printing theoretical statements.

The example that I gave is the simplest example for a bottom-up migration strategy. How can such a strategy work then? If I put the jar with no dependency, a.jar, on the module path, then the B class (in b.jar on the classpath) would not be able to load the A class. I would appreciate an explanation with examples (codes, and java commands). I would really like to see how B class can access A class.

[Stephan van Hulst]

Edmund Yong wrote:I honestly don't understand what you're talking about. Is there really such a concept as "observable" modules and "readable" modules, or is it something that you *thought* it is? The book could have been clearer with some examples, instead of just printing theoretical statements.

It's not like I just make up stuff just because I think it's funny. Take a look at the package summary for java.lang.module and see if the description helps you any.

The example that I gave is the simplest example for a bottom-up migration strategy. How can such a strategy work then? If I put the jar with no dependency, a.jar, on the module path, then the B class (in b.jar on the classpath) would not be able to load the A class. I would appreciate an explanation with examples (codes, and java commands). I would really like to see how B class can access A class.

Such a strategy really is making life more difficult for yourself. The whole point of the unnamed module is that you can put dependent modules on the module path first, and then slowly migrate dependencies from the unnamed module to proper modules. Think about it: Why would you write a JAR that makes use of a Java 9+ module, and then not immediately make it a Java 9+ module as well?

First migrate your dependent JARs, then their dependencies.

[Paul Anilprem]

It will work. Just add --add-modules com.test.a to your command. i.e.

java -p mod --add-modules com.test.a  -cp b.jar com.test.b.B

Without this option, it won't work because of the reason explained by Stephan.

[Paul Anilprem]

Stephan van Hulst wrote:
The whole point of the unnamed module is that you can put dependent modules on the module path first, and then slowly migrate dependencies from the unnamed module to proper modules.

This is confusing as hell!

Stephan van Hulst wrote:
Think about it: Why would you write a JAR that makes use of a Java 9+ module, and then not immediately make it a Java 9+ module as well?

Because the jar depends on some other non-modular jars.

[Jeanne Boyarsky]

Edmund Yong wrote:I honestly don't understand what you're talking about. Is there really such a concept as "observable" modules and "readable" modules, or is it something that you *thought* it is? The book could have been clearer with some examples, instead of just printing theoretical statements.  

This was a really tricky chapter to write. The exam expects you to know it at the level of "theoretical examples". And it gets confusing when trying it too. I was worried that by covering too "deeply", people would think they had to understand all that and get even more confused.

[Edmund Yong]

I ran the program as follows:

java -p mod --add-modules com.test.a  -cp b.jar com.test.b.B

and now it works. I think I understand what Stephan meant now.

Another thing that I want to clarify is about named and automatic modules. They wouldn't be able to read any unnamed modules from the classpath, right? Below is a question from Sybex IZO-816 Test Bank. Answer (B) is supposed to be a correct answer, but I don't think it is correct. The correct answers should be A, C, E and F, right?

A(n) _____ module can reference classes in a(n) _____ module.
Assume the package is exported as needed. (Choose all that apply).

A. automatic, named
B. automatic, unnamed
C. named, automatic
D. named, unnamed
E. unnamed, automatic
F. unnamed, named
G. None of the above.

[Paul Anilprem]

Edmund Yong wrote:I ran the program as follows:

java -p mod --add-modules com.test.a  -cp b.jar com.test.b.B

and now it works. I think I understand what Stephan meant now.

Another thing that I want to clarify is about named and automatic modules. They wouldn't be able to read any unnamed modules from the classpath, right? Below is a question from Sybex IZO-816 Test Bank. Answer (B) is supposed to be a correct answer, but I don't think it is correct. The correct answers should be A, C, E and F, right?

A(n) _____ module can reference classes in a(n) _____ module.
Assume the package is exported as needed. (Choose all that apply).

A. automatic, named
B. automatic, unnamed
C. named, automatic
D. named, unnamed
E. unnamed, automatic
F. unnamed, named
G. None of the above.

There are two kinds of modules - named and unnamed.

There are two kinds of named modules - explicitly named and automatic.

Explicitly named modules can "read" only exported types of other named modules with appropriate requires clauses.

Automatic modules and the Unnamed module can "read" all exported types of named modules + all types of the unnamed module, without any requires clauses.

(Ref: http://openjdk.java.net/projects/jigsaw/spec/sotms/ )

Therefore, options A, B, C, and F should be correct.

[Edmund Yong]

Answer E is also correct based on the errata below.

https://www.selikoff.net/ocp11-2/

So A, B, C, E, F are the correct answers.

[Paul Anilprem]

Edmund Yong wrote:Answer E is also correct

Right. Missed that one.

[Edmund Yong]

The following table appears on page 316 of the Sybex 816 book by Scott and Jeanne. It doesn't say anything about automatic modules being able to read unnamed modules. In fact, from this table, named and automatic modules are the same in that they can only read named/automatic modules (those on the module path only). So is there something wrong in this table, or I misinterpret again?

-----------------------------------------------------------------------------------------
Property                        Named               Automatic       Unnamed
-----------------------------------------------------------------------------------------
A ____ module contains a        Yes                 No              Ignored if present
module-info file?

A ____ module exports which     Those in the        All packages    No packages
packages to other modules?      module-info file

A ____ module is readable by    Yes                 Yes             No
other modules on the module
path?

A ____ module is readable by    Yes                 Yes             Yes
other JARs on the classpath?

[Jeanne Boyarsky]

You can think of unnamed modules as "sorta" modules. They have some of the powers of named modules simply by being on the module path. But they don't have all of them due to not having a module-info.java file. (So Java has to assume things like exporting all packages)