Proposed enhancement to Layer API

[Thomas Watson]

Alan Bateman <Alan.Bateman at oracle.com> wrote on 01/05/2017 06:23:46 AM:
> I'm curious what the typical use-case is for this. Most of time that
> I've seen discussions on fragments then it was about adding i18n 
> resources but there are other ways to do that sort of thing (i18n 
> bundles can be deployed as service provider modules for example).  
> An approximate equivalent of fragments here is patching where code 
> is compiled or run "as if" it's part of a host module. This is 
> important for tests that are in the same package as the API under 
> test or other ad hoc patching or testing needs where classes or 
> resources in a module need to be overridden.
> 
> In any case, exposing an API to add packages dynamically has a 
> number of implications. To date then the layer API wasn't really 
> intended to create layer with a single larval module so I think we 
> would need conclusions on this topic on the JSR list but putting in 
> support for that.
> 
> -Alan

The most typical usage of fragments is to deliver i18n and native code for 
a specific platform.  Typically the i18n resources are delivered in a 
package that already exists in the host bundle because the host bundle 
usually will contain the default i18n resource in the package.  Native 
code delivery doesn't involve packages, so I don't see an issue here for 
JPMS.

Adding new API packages with a fragment is not that common and I would 
argue that it is an anti-pattern to do so in OSGi, with one exception. One 
valid scenario involves boot strapping the framework itself.  In OSGi 
there is something called Framework Extensions which get modelled as 
fragments of the framework itself (the system.bundle).  Without going into 
much detail, they basically give a hook point where code can be inserted 
into the bootup and shutdown process of the framework.  Framework 
extensions can also provide additional API that is exported by the 
system.bundle.

My POC for JPMS-OSGi integration is implemented as a Framework Extension 
so I can hook into the bootup of the Framework before any classes are 
loaded out of bundles that are modelled as JPMS modules.

I'm sure others have found some 'valid' reason for exporting additional 
API from fragments, but I would argue that these scenarios can live with 
the restriction that the host bundle must be re-resolved in order to 
properly merge in the fragment packages.  Support for dynamic attachment 
of fragments to already resolve hosts is not mandated by the OSGi 
specification.  There are many challenges in doing that, which I think 
should be avoided for simplicity of the specification.  I know the Apache 
Felix framework implementation does not support dynamic attachment of 
fragments, except for system.bundle fragments.  The Eclipse Equinox 
framework implementation does support dynamic attachment, but with 
limitations.  For example, a fragment cannot be dynamically attached if it 
adds additional requirements to the host that effect class loading. 
Fragments are an awfully complicated concept that went way to far in OSGi, 
the result is a terrible complication to the specification.  It would have 
been far more simple to limit fragments such that they cannot add 
additional package exports or requirements to their host.

My recommendation would be to avoid such complications in JPMS.  I can 
live with 'advanced' fragment usage requiring the host bundle be 
re-resolved with the fragment in order to properly merge the fragment's 
capabilities and requirements into the host.

Tom