Configurations... (Was: Re: Module-system requirements)

[mark.reinhold at oracle.com]

2015/3/11 6:38 -0700, david.lloyd at redhat.com:
> ...
> 
> Maybe what we need is a clearer definition of "Configuration" as it is 
> only defined as a side-effect of Resolution: "The resulting 
> configuration contains all of the code and data required to compile or 
> run the initial module."   And Linking is AFAICT the first section that 
> implies that Configurations actually contain modules in any way.  This 
> might help me understand what a tree topology actually means.

A configuration is the result of resolution and service binding.  You
can think of it as a graph, with modules for nodes, edges for module
dependences, and edges (of a different color) for service-provider
bindings.

I'm pretty sure that a configuration, in this sense, is not analogous
to what you call a module loader in your system.  A configuration can
be loaded by a single class loader, multiple class loaders, or even one
class loader per module, but the module system shouldn't mandate any
particular approach.

If you build a dynamic configuration on top of the initial configuration,
and then another on top of that, as you might do in something like an
application server, then the union of their graphs will be a DAG (at
least) but the configurations themselves are just in a list, somewhat
like a search path.  You can imagine having multiple such lists sharing
prefixes, i.e., a tree of configurations, but to resolve a dependence in
any particular configuration you only need to consult its parent
configurations.

If configurations can be related in a more general way, i.e., in a DAG,
then the resolution algorithm becomes more complex.  Do we actually need
that?  I've yet to see any use cases.

- Mark