Proposal: #NonHierarchicalLayers (+ #LayerPrimitives)

[Thomas Watson]

> From: mark.reinhold at oracle.com
> > The caching comes with its own price in code complication and 
performance
> > cost to load.  Doing this lazily would greatly simplify this and 
should
> > 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 
bundle
> > framework fragment.  To make this work the list of equinox framework
> > packages and the list of packages for framework fragment must be 
specified
> > for the framework module descriptor by the launcher.  For my POC I 
just
> > hardcoded these packages directly into the launcher.  In the general 
case
> > 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 
packages
> > 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 
restart. 

> 
> If I understand §3.15 of the OSGi Core R6 specification [6] 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 
of
> 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 
information
> 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 
not required.

> > 
> > There are framework independent launchers that only use OSGi APIs (BND
> > tools has one such example).  It would be beneficial if these 
launchers
> > 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 
modest
> 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 
system.bundle fragments.

Tom