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
