Proposal: #NonHierarchicalLayers (+ #LayerPrimitives)
tjwatson at us.ibm.com
Mon Mar 6 21:46:20 UTC 2017
> From: mark.reinhold at oracle.com
> > The caching comes with its own price in code complication and
> > cost to load. Doing this lazily would greatly simplify this and
> > result in better performance for really large installations. We have
> > common cases with 1000s of bundles installed.
> Thanks for the additional background, but this still sounds like a
> performance problem that can be solved at a higher level rather than
> in the JVM itself.
> (Perhaps, in the long run, a future revision of the OSGi specification
> should add an API to support the caching of bundle package lists.)
I have my doubts the Private-Package header will become anything standard
in OSGi. Similar to how I would not like to list private packages in a
module-info.java file, I would not like having to specify the private
package list in the bundle manifest.
Of coarse that is not really what you are suggesting. Instead you are
suggesting the OSGi wiring API could be enhanced to have something similar
to the ModuleDescriptor.packages() method to return a cached set of
package names. The issue is that information is not needed by the
framework (at least as of yet) and should not be needed by any other
bundle installed in the framework. I would have a hard time proposing
such a method back to the specification.
> > In fact, this is how my JPMS POC is implemented, in its own system
> > framework fragment. To make this work the list of equinox framework
> > packages and the list of packages for framework fragment must be
> > for the framework module descriptor by the launcher. For my POC I
> > hardcoded these packages directly into the launcher. In the general
> > the launcher will not know what framework fragments will be installed
> > during the lifetime of the framework instance. The addPackage and
> > addExports method would allow such a launcher to handle when new
> > are added from a framework fragment.
> How critical is this general case? How often are framework fragments
> actually used in a way in which they cannot be identified when the
> framework is launched?
I know this is important for Eclipse because there are many framework
extensions implemented by various eclipse projects as well as others.
ObjectTeams and aspectJ weaving projects are two that come to mind.
Equinox itself has something called Equinox regions which runs on any OSGi
framework as a framework extension. These framework fragments almost
always have their own private packages and often have additional APIs that
are exported by the system bundle. The way Eclipse provisions these
extensions depends on the ability to resolve them dynamically, without a
> If I understand Â§3.15 of the OSGi Core R6 specification  correctly
> then a framework implementation is not required to resolve framework
> fragments (a.k.a. "extension bundles") dynamically, though it is allowed
> to do so (see steps 2 and 3 of the lifecycle description at the bottom
> p. 85). If an OSGi implementation can always restart when a framework
> fragment is resolved or refreshed then isn't that a natural time to scan
> the fragment's bundle for its packages, possibly caching that
> for later use?
Any practical framework will support attaching system.bundle fragments
dynamically. I'm most familiar with Equinox and Felix, and I know both
these frameworks support this for system.bundle fragments. I also know a
framework cannot pass the compliance tests for system.bundle fragments
without supporting dynamic attachment, despite the spec stating that it is
> > There are framework independent launchers that only use OSGi APIs (BND
> > tools has one such example). It would be beneficial if these
> > could do the right thing when running on JPMS. The addPackage and
> > addExportToAll method would make this possible.
> Yes, but could this problem be addressed in some other way? Would
> additions to the OSGi API allow a launcher to do a bit of introspection
> on the framework being launched?
Perhaps, but for my usecases the launcher simply cannot know what will be
installed by a management agent later. And to be a practical
implementation the framework really needs to support dynamic attachment of
More information about the jpms-spec-experts