Inconsistency with service loading by layer or by class loader

[Alan Bateman]

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20241214/001fcb37/attachment.htm>