Module isolation

[Bryan Atsatt]

Stanley M. Ho wrote:
> Resend.
>
> Bryan Atsatt wrote:
>> ...
>> Stanley's idea was that a Repository implementation could return a
>> *copy* of a ModuleDefinition created by a different Repository. Such a
>> Repository would in fact form an isolation context. And caching Module
>> instances becomes trivial: each definition can just have one as a field.
>>
>> While there are definite lifecycle issues here between such repository
>> instances, they are probably solvable.
>>
>> And then we really *do* have an exact analogue of the loader delegation
>> model, in which:
>>
>>    Repository       ~= ClassLoader
>>    ModuleDefinition ~= Class
>>    Module           ~= Object
>>
>> Isolation of classes requires different Class instances. So isolation of
>>  modules requires different ModuleDefinition instances.
>
> Yes, that's the basic idea for isolation. In addition, the ModuleSystem
> object is the one actually handling the module instances' instantiation,
> initialization, and release, so the repository implementors do not have
> to be aware of most of the module runtime's complexities.

It seems to me that if we're going to follow this model, then:

1. There is a 1:1 relationship between ModuleDefinition instances and
Module instances.

2. Given #1, why does the getModuleInstance() method on ModuleDefinition
need to call through to the ModuleSystem? As it is, the ModuleSystem
must keep a separate map, which seems like overkill. The definition type
will be specific to the module system, so it can always instantiate the
correct type, and simply cache it in a field.

3. The ModuleDefinition copy operation and semantics must be defined. We
could simply implement Cloneable, or create a copy() operation. Either
way, it needs to be clear *what* is copied; I would think we would copy
all of the data *except* for the ModuleDefinitionContent.

>
> - Stanley
>