• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Devaka Cooray
  • Tim Cooke
Sheriffs:
  • Rob Spoor
  • Liutauras Vilda
  • paul wheaton
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Mikalai Zaikin
  • Carey Brown
  • Piet Souris
Bartenders:
  • Stephan van Hulst

Sybex 819 - Automatic modules - Java OCP 11 Programmer II Study Guide

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I have a query about Automatic modules.
On Chapter 6 in the Java OCP 11 Programmer II Study Guide by Scott Selikoff and Jeanne Boyarsky it's written "A key point to remember is that code on the classpath can access the module path. By contrast, code on the module path is unable to read from the classpath."
Also, looking at Table 6.3 (see attachment) I understand that Automatic modules cannot access unnamed modules on the classpath.

However, I read elsewhere the following:
Remember that modular code cannot access code present on the -classpath but "automatic modules" are an exception to this rule. When a non-modular jar is put on --module-path, it becomes an "automatic module" but it can still access all the modular as well as non-modular code. In other words, a class from an automatic module can access classes present on --module-path as well as on -classpath without having any "requires" clause

Did I misunderstand the information in Java OCP 11 Programmer II Study Guide?


Screenshot-2020-12-19-at-15.14.26.png
TABLE 6.3 - Properties of modules types
TABLE 6.3 - Properties of modules types
 
author & internet detective
Posts: 41995
911
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Automatic modules are on the module path. That's a key difference between an automatic module (module path) vs unnamed module (classpath)
 
Ranch Hand
Posts: 45
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Early Charlemagne wrote:Hi,

I have a query about Automatic modules.
On Chapter 6 in the Java OCP 11 Programmer II Study Guide by Scott Selikoff and Jeanne Boyarsky it's written "A key point to remember is that code on the classpath can access the module path. By contrast, code on the module path is unable to read from the classpath."
Also, looking at Table 6.3 (see attachment) I understand that Automatic modules cannot access unnamed modules on the classpath.

However, I read elsewhere the following:
Remember that modular code cannot access code present on the -classpath but "automatic modules" are an exception to this rule. When a non-modular jar is put on --module-path, it becomes an "automatic module" but it can still access all the modular as well as non-modular code. In other words, a class from an automatic module can access classes present on --module-path as well as on -classpath without having any "requires" clause

Did I misunderstand the information in Java OCP 11 Programmer II Study Guide?




Hi,

Unnamed modules are on the classpath. They can access JAR files on both the classpath and the module path.

Named modules are on the module path, they cant access any unnamed module.

Automatic module are on the module path, they can access all the modular as well as non-modular code.

For example, using Bottom-Up migration strategy, you have a mix of named and unnamed modules.The named modules are the low-level that have been migrated. They are on the module path and not allowed to access any unnamed modules, but the high-level that have not been migrated are unnamed and they access the low-level(named).

Another example, top-down migration, you move all projects to module path(now they are automatic modules), then you choose the first module that has more dependencies to add the module-info to convert the automatic module into a named module. If the modules that are low-level(have less dependence) were unnamed (that is, they were in the classpath) this strategy would not work, since named modules cannot access unnamed modules.Thats why you must move all projects to module path, using this strategy.
 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm still struggling to understand this concept (Automatic Modules can or cannot access Unamed?)..I have bought the perfect duo: Scott Selikoff and Jeanne Boyarsky's book and Enthuware mock tests..can someone point where I'm wrong, please? See

Screenshot-from-2021-04-11-19-11-15.png
Scott Selikoff and Jeanne Boyarsky
Scott Selikoff and Jeanne Boyarsky
Screenshot-from-2021-04-11-19-09-30.png
Enthuware
Enthuware
 
Nicholas Barbosa
Ranch Hand
Posts: 45
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Andre Garcia wrote:I'm still struggling to understand this concept (Automatic Modules can or cannot access Unamed?)..I have bought the perfect duo: Scott Selikoff and Jeanne Boyarsky's book and Enthuware mock tests..can someone point where I'm wrong, please? See


Automatic modules can access unnamed modules.
 
Bartender
Posts: 1737
63
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
All this happened while I was away for a good long while.

The questions/complaints are essentially the ones I made recently, after searching casually (apparently too casually) to make sure I wasn't making a pointless duplicate.

I don't think that the authors acknowledged the murky stuff in the table that confused the posters here, and that I beat to death in another thread.

I would have written the same questions/complaints here in this one had I not missed its existence.

For reference, I think I searched the Modules forum and the Java in General forum, and must have mistakenly thought I searched in here as well, but failed to.

If the unclear parts are out of scope of the exam, then fine, maybe, but there are still two entries in Table 6-3 that are confusing/misleading at best.
I explained it in different ways than these posters in the thread I started after I missed this one.
 
Greenhorn
Posts: 4
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The book is partially wrong about accessibility between modules. After doing a research from multiple trusted sources, here is my summary:

# Definitions:
* A named module is on module path and with module-info.
* An automatic module is on module path without module-info. Module name is generated automatically.
* An unnamed module is on classpath and ignore module-info if it exists.

# Accessibility
* A named module can only access to a module by explicitly declare a "requires module-name" statement. Because unnamed module has no name, named module cannot access unnamed module. However, it can declare "requires automatic-module-name", so it can access automatic module.
* An unnamed module implicitly exports everything and requires all packages exported by other modules (named, unnamed, automatic)
* An automatic module implicitly exports everything and requires all packages exported by other modules (named, unnamed, automatic)


# Remain question
Not sure how java solve the cyclic dependency between automatic module and unnamed module. But I think cyclic dependency is only the rule for compiling module-info in named modules. Because there's no module-info in automatic module and unnamed module, so no compiler error related to cyclic dependency.

See: https://developer.ibm.com/tutorials/java-modularity-5/#multi-module-mode
 
Xuan Nguyen
Greenhorn
Posts: 4
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Today I try all the theories in my previous post and I can confirm that it's correct. I am confident to answer questions related to module system now.
 
She's brilliant. She can see what can be and is not limited to what is. And she knows this tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
reply
    Bookmark Topic Watch Topic
  • New Topic