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