New issue: run time eager module loading

David M. Lloyd david.lloyd at
Fri Mar 11 21:55:56 UTC 2016

On 03/11/2016 11:47 AM, mark.reinhold at wrote:
> 2016/3/2 19:22 -0800, david.lloyd at
>> It looks as though the instantiation of a Layer causes a complete load
>> of all the modules in the layer.
> What do you mean by "complete load"?  Loading all the classes?

No I mean locating and loading all of the descriptors and building all 
the wiring information for every module.

>>                                    Apart from the consequent lack of
>> dynamicism, I think this is very likely to cause problems for large
>> applications, particularly if such an application might have many
>> operation modes, some of which do not require *all* of the bundled
>> modules to be loaded every single time.
>> Can there not instead be an incremental resolution algorithm, akin to
>> how classes are lazily loaded?
> Configuring a set of modules and instantiating that configuration as a
> layer requires no more than reading the modules' descriptors.  Nothing
> else from any module definition will be read until it's actually needed.

But it does require that all the module descriptors from a given layer 
be available, and that the load time for the first load of a module in a 
layer will always be bounded by the size of the layer, rather than just 
by the dependency subgraph of the module being loaded.  Based on 
application server deployments that I know about, I think the far upper 
bound for a realistic number of modules in a layer will probably lie in 
the thousands to ten thousands range (though there is always the outlier 
case where someone has to push it to see how far it goes...), which 
might translate into a substantial startup overhead.  Another potential 
issue is requiring that all modules be present, though this is more 
closely related to #MutableConfigurations now I think; I suspect this 
issue could be mitigated with an acceptable solution to that issue.

> If you really want to avoid configuring all modules in certain operation
> modes, do layers not provide sufficient flexibility?  Load the core of
> your application into the boot layer, figure out which modules you need
> for the requested operation mode, and then create an additional layer to
> load those modules.

That can work in some cases, but only if things are loaded one 
additional time (rather than on-demand as configuration changes, for 
example) or in such a way that you could just keep adding layers.  But 
in the event of one large intermeshed layer, this won't work without 
#MutableConfigurations and/or #NonHierarchicalLayers and something to 
coordinate the load.


More information about the jpms-spec-experts mailing list