Mutable modules

[David M. Lloyd]

On 05/18/2016 10:35 AM, Alan Bateman wrote:
> 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.

At present, you can remove a module or a bundle even if existing 
dependent module classes are statically referring to their contents. 
It'll work fine as long as those classes haven't been loaded yet.  So 
we'd basically be taking away this capability with the code as it is, if 
we try to put existing deployments or bundles into named Modules.

Another thing presently possible is expanding the existing class path of 
a deployment module, and replacing class contents (again this may fail 
if any of the replaced classes were already loaded).

To expand it more to a logical statement, the set of capabilities 
allowed to a class loader is greater than the set allowed to a named 
module, so as long as this is true, moving to named modules will 
necessarily cost functionality.

> 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.

Ah okay, so the access control angle is one I didn't examine.  In some 
cases access control is split between HotSpot and the JDK, and I assumed 
that the new access controls were all on the JDK side, which was a bad 
assumption it seems.

> 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.

Would it be possible to somehow allow the unnamed module to, well, have 
a name (and a version string), so that it appears in stack traces?

-- 
- DML