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

Christian Stein sormuras at gmail.com
Fri Mar 26 10:09:45 UTC 2021


Thank you for the clarification, Alan.

First, I fixed the problem as you suggested by adding
--add-modules ALL-SYSTEM to the java command.
It yielded warnings about incubator modules, though:

  WARNING: Using incubator modules:
  jdk.incubator.vector, jdk.incubator.foreign

Next, I went with --add-modules ALL-DEFAULT
That fixed the runtime issues with jdk.xml.dom

Later that day, Jorn Vernee suggested another
fix [1], that works (for Bach) also at runtime without
using the --add-modules X at the command line.
Basically, it puts a ModuleFinder.ofSystem() as
the after component of the custom module layer
Bach creates for running ToolProvider services.

I really need to dig deeper into the lair of module
layers - especially as I want to enable assertions
by default in the classloader(s) created for/by the
custom module layer.

Cheers,
Christian

[1]:
https://github.com/sormuras/bach/commit/940bf900c448177cc5cc5410ff604bad8197b59c


On Thu, Mar 25, 2021 at 4:17 PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

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


More information about the jigsaw-dev mailing list