On 14/03/2025 10:54, Simone Bordet wrote:
:
The question is whether there is a way for a child ModuleLayer to
perform the equivalent of "--add-modules", but programmatically at
runtime, that would add the module to the graph?
Module layers are immutable so you can't modify the boot layer at runtime.
In this case, the initial module is a named module that doesn't
transitively require java.instrument so that module is not in the boot
layer. If they server was started with -javaagent then the
java.instrument would be in the boot layer. In JEP 261 the
recommendation for container apps, like this one, is to run with
--add-module ALL-DEFAULT and it will ensure that any module in the
run-time that exports an API will be in the boot layer.
A comment in passing is that it's surprising that there are modules in
ee$N layers requiring java.instrument. The classes in this modules
aren't normally used by libraries and applications, instead they work as
the side channel for agents.
As a side question, I was wondering what is the benefit of using
ModuleLayers versus just using ClassLoaders.
I can think of earlier error detection: if the ModuleLayer is not
setup correctly (as above) I get an early error, which I would only
get much later at runtime if I was using ClassLoaders.
Right, that's part of reliable configuration where errors are detected
in pre-flight checks rather than failing mid-flight. The other part is
strong encapsulation. ClassLoader can provide isolation but they are
just part of the setup as class loaders otherwise just load classes.
-Alan
