On 14/12/2024 00:02, David Lloyd wrote:
:
The problem with having one (or a few) broad layer for all named
modules is twofold: first, that every module that *might* be needed
for an application must be found and loaded before *any* module is
able to be loaded. This works in some simpler packaging scenarios but
is too startup-heavy in cases with very large numbers of modules. The
"--add-modules" switch on the Java launcher is a direct result of
forbidding late binding of modules. From a usability perspective, this
is already far from ideal, and if you start talking about hundreds or
thousands of modules, it becomes completely unworkable. The second
problem is that it makes it very difficult to support any kind of
dynamicity (for example adding additional plugins/service
implementations at run time) since an outsized amount of static
analysis must be done to categorize the layers, whereas lazily loading
layers solves the problem easily and elegantly.
If the real issue here is "too startup-heavy" then that might be
something to focus on.
The --add-modules command line option serves many cases where additional
modules may be needed. The intention with `--add-modules ALL-DEFAULT`
was to help container like applications that in turn load other
applications at run-time. The container can of course create a module
layer before creating layers for applications and the only real
challenge there is the JDK "platform modules", cue the requirement for
"dynamic augmentation of platform modules". We only got so far on this
topic, but enough for needs such as allow the JMX agent or a Java agent
be loaded into a running VM when the modules required to support that
are not in the boot layer.
Module layers works well for plugins and services and are of course
created on-demand. I don't think I understand what you mean by "outsized
amount of static analysis must be done to categorize the layers", is
this a reference to your exploration into multi-parent configurations
and one-module-per-layer?
-Alan
