The runtime environment needs to have a way that developers can impose version consistencies that make sense. In some cases it is just data consistencies which can be managed literally with data construction.
But when code versions are mixed in with data versions, the runtime context needs to yield something too. It could be an application, ThreadLocal value providing a version identity or something that the module versioning injects into a Thread object when it is created. It may need to be mutated by the app or the module system. In some cases it might make sense for module version changes at runtime to control Thread lifecycle events too. Runtime code updates need to remain possible with predictable and controllable outcome. Gregg Sent from my iPhone > On May 18, 2016, at 10:35 AM, Alan Bateman <alan.bate...@oracle.com> 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. > > 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
