[Question] Accessibility of each modules

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Question] Accessibility of each modules

KUBOTA Yuji
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.

I ran quick-start's example program on java 9+181 and 8u141, and
confirmed the following results.
* Named modules can call autonamed modules.
* Automatic modules can *NOT* call named modules.
* We can run unnamed modules with only unnamed modules.

You can reproduce it by https://github.com/ykubota/jigsaw-sample-accessibility

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.
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.

Is my understanding correct?

Thanks,
Yuji
Reply | Threaded
Open this post in threaded view
|

Re: [Question] Accessibility of each modules

Alan Bateman
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
Reply | Threaded
Open this post in threaded view
|

Re: [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 <[hidden email]>:

> 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
Reply | Threaded
Open this post in threaded view
|

Re: [Question] Accessibility of each modules

Alan Bateman
On 05/09/2017 14:08, KUBOTA Yuji wrote:

>
> 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
>
The issue here is that org.astro is not resolved because no module
requires org.astro. If you add `--add-modules org.astro` to the command
line then it will ensure that this module is resolved and you should see
that com.greetings reads it.

-Alan
Reply | Threaded
Open this post in threaded view
|

Re: [Question] Accessibility of each modules

KUBOTA Yuji
2017-09-05 22:16 GMT+09:00 Alan Bateman <[hidden email]>:
> The issue here is that org.astro is not resolved because no module requires
> org.astro. If you add `--add-modules org.astro` to the command line then it
> will ensure that this module is resolved and you should see that
> com.greetings reads it.

Thank you very much!

Following your advice, I could investigate the implementation how
required module add to module graphs. (e.g.,
java.lang.module.Resolver)
I think that developers should know how to create module graphs
correctly before modularing our applications step-by-step. I will
re-investigate specifications and implementations, and write an
article in my native language to help my neighbors.

Thanks again!
Yuji