Proposed enhancement to Layer API
tjwatson at us.ibm.com
Thu Jan 5 14:05:50 UTC 2017
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.
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
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
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.
More information about the jigsaw-dev