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
