<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
On 14/12/2024 00:02, David Lloyd wrote:<br>
<blockquote type="cite" cite="mid:CANghgrRPuVJDMpxBiAwcz_TQhOzYKE-E6F_QiG=SkS9nBEYr8Q@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">:<br>
</div>
</div>
<div class="gmail_quote gmail_quote_container">
<div><br>
</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div>
</div>
<br>
</div>
</blockquote>
If the real issue here is "too startup-heavy" then that might be
something to focus on.<br>
<br>
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.<br>
<br>
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?<br>
<br>
-Alan<br>
<br>
<br>
<br>
<br>
</body>
</html>