• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Paul Clapham
  • Bear Bibeault
  • Jeanne Boyarsky
Sheriffs:
  • Ron McLeod
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Jj Roberts
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • salvin francis
  • Scott Selikoff
  • fred rosenberger

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

 
Ranch Hand
Posts: 227
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:



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:





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?
 
Saloon Keeper
Posts: 12428
269
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 12428
269
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 227
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 12428
269
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
Enthuware Software Support
Posts: 4470
43
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Enthuware Software Support
Posts: 4470
43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.

 
author & internet detective
Posts: 40239
819
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 227
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I ran the program as follows:



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
Enthuware Software Support
Posts: 4470
43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Edmund Yong wrote:I ran the program as follows:



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
Ranch Hand
Posts: 227
1
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Enthuware Software Support
Posts: 4470
43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Edmund Yong wrote:Answer E is also correct


Right. Missed that one.
 
Edmund Yong
Ranch Hand
Posts: 227
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?


 
Jeanne Boyarsky
author & internet detective
Posts: 40239
819
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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)
 
Curse your sudden but inevitable betrayal! And this tiny ad too!
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic