Difference of module jdk.xml.dom and module jdk.zipfs

[Alan Bateman]

On 25/03/2021 14:59, Christian Stein wrote:
> Hi,
>
> Besides their names, contents and purposes. (-:
>
> So, what's the difference of module jdk.xml.dom and
> module jdk.zipfs in respect to their visibility(?) at
> compile and run-time?
>
> Suppose, there's a module test.base declared as:
>
>    module test.base {
>       requires jdk.xml.dom;
>       requires jdk.zipfs;
>    }
>
> Compiling it with javac (from JDK 16) works like a charm.
> Running it in a custom module layer fails with:
>
>    java.lang.module.FindException:
>      Module jdk.xml.dom not found, required by test.base
>
> If I comment out the "requires jdk.xml.dom;" directive,
> everything is fine. Same, if I start the test running process
> with "--add-modules DEFAULT" as an argument.
>
> Am I setting up the module layer in a wrong manner? [1]
> Are there differences between system modules?
> Like all = system 1 + system 2 + incubating?
jdk.zipfs is a service provider module. It `provides` an implementation 
of j.nio.spi.FileSystemProvider. The java.base module `uses` this 
service so this is the reason why jdk.zipfs is in the boot layer. 
Running with --show-module-resolution is a useful way to understand why 
a module is in the boot layer.

jdk.xml.dom exports org.w3c.dom APIs that are not defined by Java SE. 
It's not in the boot layer in your test because none of the modules 
requires it.

When you attempt to create the configuration for a module layer at 
runtime then you are (I assume) using the configuration for the boot 
layer as the parent. The jdk.xml.dom module is not observable with the 
module finder you are using and it's not in the parent configuration so 
this is the reason why you get the FindException "module jdk.xml.dom not 
found" exception.

There isn't any way to add to the set of modules in the boot layer at 
runtime so you have the help the module system by running with 
-add-modules jdk.xml.dom. More generally, a container-like program that 
is loading plugins and creating module layers at runtime will probably 
want to run with --add-modules ALL-SYSTEM to ensure that all "system" 
modules are in the boot layer and avoid disappointment at runtime.

-Alan