Hi Bryan, Bryan Atsatt wrote:
Can you please explain the use case for releaseModule()?
If a repository instance is long-lived, the instantiated module instances from the module definitions in the repository would be cached for a long period of time; calling releaseModule() could help freeing up resources when necessary, without requiring the repository instance to be shutdown. This is also a use case from NetBeans. Also, when a module definition is reloaded/uninstalled, or when the repository is shutdown, we will disable the module definitions in the repository from the module system so any existing module instance would be released and no new module instance can be instantiated. However, releasing the module instance alone is not sufficient because that module instance may be referenced by some importers. Hence, we want to call releaseModule() on the importers as well for these module instances to eventually become unreachable and be GCed.
Would you agree that if we did not support releaseModule(), caching the Module instance in the ModuleDefinition would eliminate some complexity?
No. I actually think caching the Module instance in the ModuleDefinition would add complexity to the design and the implementation. If the module instances are cached in the ModuleSystem, the ModuleSystem could fully control the access of these module instances and update/change them internally. ModuleDefinition is supposed to be stateless, and I think it should be kept this way.
Isolation requires creating a separate repository instance that wraps another, and hands out *copies* of definitions from the underlying instance. We simply need a standard way to make such a copy, one that does not require knowing the actual subtype.
If I understand what you are trying to do, you want to construct a new repository instance with module definitions that are based on some module definitions in an existing repository instance. To do that, we could either go with the approach of constructing new ModuleDefinition, or as you suggested - cloning. However, I don't think cloning is the right general solution here - there are many module definitions that are unsuitable for cloning (e.g. platform module definitions). My assumption is that the developer creating the separate repository instance is possibly the one creating the original repository instance, so I don't understand why he can't simply construct a new ModuleDefinition with an existing ModuleDefinitionContent. - Stanley
