[Question] Accessibility of each modules

[KUBOTA Yuji]

Hi Alan,

Thank you very much for your quickly and detailed explanation!

I think that your explanation make sense except accessibility of automatic
module.
My following example program shows that automatic module can't read
exported package by explicit module.

$ /jdk-9/bin/jar -d --file mlibs/org.astro.jar
org.astro jar:file:///jigsaw-sample/mlibs/org.astro.jar/!module-info.class
exports org.astro
requires java.base mandated

$ /jdk-9/bin/jar -d --file libs/com.greetings.jar
No module descriptor found. Derived automatic module.

com.greetings automatic
requires java.base mandated
contains com.greetings

$ /jdk-9/bin/java -p mlibs:libs -m com.greetings/com.greetings.Main
Exception in thread "main" java.lang.NoClassDefFoundError: org/astro/World
        at com.greetings/com.greetings.Main.main(Main.java:7)
Caused by: java.lang.ClassNotFoundException: org.astro.World
        at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
        at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
        ... 1 more


Thanks,
Yuji


2017-09-05 20:31 GMT+09:00 Alan Bateman <Alan.Bateman at oracle.com>:
> On 05/09/2017 12:01, KUBOTA Yuji wrote:
>>
>> Hi all,
>>
>> I have a question about accessibility of each modules: unnamed,
>> automatic and named modules.
>> * unnamed: the JAR compiled by java 8 and speficied by --class-path.
>> * automatic: the JAR compiled by Java 8 and specified by --module-path.
>> * named: the modular JAR.
>
> For the modular JAR case then the term to use is "explicit module".
>
>>
>> I ran quick-start's example program on java 9+181 and 8u141, and
>> confirmed the following results.
>> * Named modules can call autonamed modules.
>
> Yes, assuming the explicit module reads the automatic module. As an
> automatic module exports all packages then it means code in the explicit
> module can access all public members of public classes in the automatic
> module.
>
>> * Automatic modules can *NOT* call named modules.
>
> Automatic modules read all named modules (in the module graph), they also
> read all unnamed modules. I have not studied your github project but you
> should see that code in the automatic module can access all public members
> of public classes in packages exported by the explicit module (because it
> reads the explicit module).
>
>> * We can run unnamed modules with only unnamed modules.
>
> I'm not what you mean by this because you can mix the class path with
named
> modules. When you run HelloWorld on the class path then you are doing
this,
> although it might not be obvious.
>
> If it helps then the code in an unnamed module an access all public
members
> of public classes in all unnamed modules. It can also access all public
> members of public classes in the packages exported by named modules
> (automatic modules are named modules, they export all packages).
>
>>
>> I guessed that every modules can be accessed each other if
>> `--illegal-access=permit` or/and `--add-exports` is given, but it does
>> not seems to be fine.
>
> The `--add-exports` option is for breaking encapsulation, it can be used
to
> change a module so that it exports an otherwise concealed package to
another
> named module or to all unnamed modules.
>
> The `--illegal-access=<value>` option is specific to the standard and JDK
> modules.
>
>> I guess that modules and classes (unnamed module) cannot be existed at
>> the same time because `BuiltinClassLoader` seems to branch by
>> `packageToModule` field in it.
>
> No, that is just an implementation detail. The issue that was chosen not
to
> tackle in JDK 9 is the issue of multiple modules in the boot layer with
the
> same non-exported package. This topic has a lot of complexity and
> compatibility issues for (non-JDK) code. It will be looked in the future.
>
> -Alan