> In some cases we have the full contents, but in other cases we allow > dynamic deployment contents to be updated or added at run time (mostly > for development purposes but it can be practical and useful to add > contents at run time as well in certain cases). Because of the way that
> our linkage algorithm is designed, our current Jigsaw integration > prototype just adds all contents after the fact (mainly because of the > dependency chain involved in building our modules, in which the contents > simply aren't available at the time we establish the class loader and > layer). > > It is theoretically possible to rewrite our linkage algorithm to use the > first known set of packages as the static package set for a module, but > we'd still need the ability to add contents anyway, or else drop the > feature entirely, which would be unfortunate. > > -- > - DML > In OSGi we also have this ability (known as fragments). In my JPMS-OSGi integration POC I modelled a host module and all of its attached fragments as a single JPMS module. I did this because in OSGi the host content and all of its attached fragment content are loaded with a single class loader and fragments are able to deliver additional classes to packages already contained in the host module. With JPMS I can not map a single class loader to multiple modules which contain the same package, so I opted to model fragments as being part of the host module. Fragments are also able to deliver classes in packages that are previously unknown to the host (module). In theory fragments can be dynamically attached to an already resolved host (module) which implies that we need to be able to dynamically add packages to the existing host module. With that in mind, if we wanted to support dynamic attachment of fragments then the ability to add packages would also be useful to me. An alternative approach would be to map the host module class loader to fragment modules as well as the host module but only have the fragment declare packages that are not already declared by the host module. This would require that each fragment is contained in its own isolated layer so that we can dynamically map the original host class loader to newly attached fragment modules. But this complicates things in many ways. For example, requiring a module grants a module access to all packages exported by the required module. Fragments are allowed to export additional packages. Allowing the set of exports to be dynamically added to an already in use module may break to rules for configurations that are built on top of the layers containing the host modules. I'm unsure what methods like addExportsToAll should do for existing modules that are already resolved (linked?) against the module you are adding an export to? Does it dynamically grant access to the exported package at runtime? What if that introduces a split package to the requiring module? So far I have decided to simply not support dynamic attachment of fragments that contain new packages for the JPMS-OSGi integration. Instead the host module must be re-resolved so that the new fragment content can be properly merged into the host module in JPMS. This simplifies things but comes at the cost of not properly supporting dynamic attachment of fragments that deliver new packages. Tom
