Mutable modules

[David M. Lloyd]

I just raised this issue on the JPMS experts list, but I want to discuss 
the technical issues here.

On 05/18/2016 08:23 AM, David M. Lloyd wrote:
> Related to #MutableConfigurations, in order to support dynamically
> changing deployments for containers (including, I believe,
> OSGi-compliant containers) where deployments are modules, it is
> necessary to allow a module's dependency graph to be mutated at run
> time.  The behavior of such things in existing systems is such that any
> already-loaded/linked dependency classes remain, thus such action is
> usually only guaranteed to be "safe" when adding dependencies, or when
> it can be somehow guaranteed that no lingering dependency classes exist,
> or that such lingering classes can safely be ignored.
>
> While this operation isn't 100% safe, it is supported by containers in
> existence today, so should at least be considered.

The primary obstacle to this request seems to be that module packages 
declared inside the JVM in Module::define_module, whose purpose I 
haven't decoded yet but am assuming that it is used to look up the 
module info for a given package name when constructing exception stack 
traces (I deduced this from the fact that the module name and version 
are passed in as strings here).  Am I correct about this?  Does this 
code have any other function?

Would it not be possible to instead use the class itself, which already 
has a reference to the Module, to get this sort of information?  The 
String-ified module version could simply be stored as a field on the 
Module (as could the String-ified location information, whose purpose I 
have not yet determined).

-- 
- DML