The baby and the bathwater (the return)

[Alan Bateman]

Hi all,
There were discussions on that list [1] about the fact that beginning with Java 9, there were 2 ways to deploy modules, classpath vs module-path.
I've discovered last Friday there that are not 2 configurations but 3 configurations.
You can also use jlink [2] and in that case, the modules are not loaded though the module-path but are considered as system modules, so a library should also be tested with that configuration.
In my case, Spring Boot annotations scanning works with the classpath, works with the module-path but fails if deployed as system modules [3].

The module path is exactly as Jon said.

I haven't looked at your demo in github but it sounds like the issue is
the code that does the scanning the module path (Spring code? Some other
library?). Is it limited to modules that are packaged as modular JAR
files or is it that it just scans the value of the jdk.module.path
property? In terms of behavior then there shouldn't be any difference of
course, code in a module loaded from the application module path should
work the same as when the module is linked into the run-time image. In
both cases, the modules are mapped to the application class loader.

Separately, it would be interesting to know if the scanning is all
observable modules or the modules that have already been resolved and
are in the boot layer. If this is all "discovery" then I assume it must
be looking for observable modules that have not been resolved as they
will be candidates to load into a child layer. There may be some
interesting topics to discuss there but it's completely independent on
where the modules are deployed on the application module path or linked
into the run-time image.

-Alan

[Jochen Theodorou]

Rémi,
Generally, you should consider the runtime "module path" to be composed
of three elements: the upgrade module path (--upgrade-module-path), the
system modules (--system) and the user module path (--module-path).
Depending on your requirements, you may want to take --patch-module into
account as well.  At compile time there is also the source path
(--source-path or --module-source-path) to consider.
While this may seem complicated, it is analagous of the pre-Jigsaw world of
    -Xbootclasspath/p:  -bootclasspath  -Xbootclasspath/a: -classpath
(and -sourcepath at compile time)

with one major difference... you rarely had a reason to use
bootclasspath in any way. The need to test such situations was very very
limited as well. jlink makes system modules a standard, classpath and
modulepath have to be tested as well now...

bye Jochen