Proposed enhancement to Layer API

[Thomas Watson]

> 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