Proposal: #NonHierarchicalLayers

[Thomas Watson]

> From: mark.reinhold at oracle.com
> > OSGi does support dynamic attachments of fragments.  The current 
> > prototype cannot do this but on Jan. 4 Thomas expressed that being 
able 
> > to add packages would enable this part of the specification. 
Re-linking 
> > everything is (according to this email) an alternative that comes at 
the 
> > cost of not supporting this feature.
> 
> True, but Thomas later recommended against complicating JPMS in order to
> support this feature of OSGi [1].  He can live with having to re-resolve
> bundles when fragments add API packages, which is not common and 
arguably
> an anti-pattern.
> 

The addPackage method would be beneficial for other reasons when adhering 
an existing module system into a JPMS Layer.

 - addPackage would allow existing module systems to avoid aggressive 
discovery of all private packages for its own modules when building a JPMS 
ModuleDescriptor.  For the existing module systems I know about the class 
loader is used extensively as the module primitive.  Requirements wire up 
the class loaders for proper class loader delegation and typically the 
APIs are declared capabilities to indicate what the modular class loaders 
can load and expose to another module class loader.  But nowhere was it 
required to aggressively discover all private packages and resources up 
front.  Having an addPackage would allow such module systems to grow the 
list of private packages lazily as it is defining classes in the packages 
that are private to the module.

- In my prototype I also have a boot strapping issue that addPackage would 
be helpful for.  In my prototype I have a launcher that assembles a module 
Layer which then holds the OSGi framework implementation.  In this case 
the launcher is using Java 9 Layer API and then is loading up a standard 
OSGi framework implementation using only OSGi standard API.  The launcher 
then assigns the framework implementation a ModuleDescriptor to represent 
the OSGi framework.  In OSGi the framework is represented by an OSGi 
bundle called the "system.bundle".  So in this case the ModuleDescriptor 
also has a name "system.bundle".  And the ModuleDescriptor has a well 
known list of OSGi APIs it exports.  But the launcher does not know the 
private implementation packages of the framework implementation.  In my 
prototype I just hack in the list of private package for the equinox 
framework, but this is far from ideal.

I did say that I could live without supporting dynamic attachment of 
fragments which provided additional packages.  But I do not want that 
compromise from me to justify not adding the method addPackage to the 
controller.  I think it would be beneficial to existing module systems 
that need to live within a proper JPMS Layer. 

It would help to understand what complications addPackage bring to JPMS 
above the other dynamic add methods already on the Module API and the 
others being proposed for the Controller API here.

Tom