Mutable modules

[Alan Bateman]

On 18/05/2016 16:04, David M. Lloyd wrote:
> 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?
For #MutableConfigurations then I think it would be useful to provide an 
example to explain what you are looking to do. Are you generating code 
at runtime into existing modules/packages and with static references to 
types that the host modules doesn't know about? Or maybe you mean more 
loosely coupled services where modules are interacting with other 
modules with a different lifetime? A simple example would help set the 
scene.

As regards Module::define_module (assuming we are talking the 
implementation in HotSpot) then the VM needs to know about the module 
before any classes are loaded from that module. It would otherwise not 
know which module that the class is a member of. and that membership is 
needed in order to do access control. Remember that this project is not 
making fundamental changes to class loading. Also there is nothing in 
the class bytes to indicate which module the class is in. If you work 
through a few examples (say with a <= v52.0 class file) and existing 
uses of ClassLoader::defineClass then I hope you'll see what I mean. I 
don't see the connection to #MutableConfigurations.

The only pieces of information that are not critical to the VM are the 
module version and location. These are passed to the VM when creating 
modules and used for diagnostics purposes only. Neither is required and 
you'll find a number of cases where dynamically modules have neither.

-Alan