tjwatson at us.ibm.com
Mon Feb 27 17:47:25 UTC 2017
> 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
> > to add packages would enable this part of the specification.
> > everything is (according to this email) an alternative that comes at
> > cost of not supporting this feature.
> True, but Thomas later recommended against complicating JPMS in order to
> support this feature of OSGi . He can live with having to re-resolve
> bundles when fragments add API packages, which is not common and
> 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.
More information about the jpms-spec-experts