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
