Proposal: #NonHierarchicalLayers (+ #LayerPrimitives)

[Thomas Watson]

mark.reinhold at oracle.com wrote on 03/06/2017 05:45:25 PM:
> So, here's an even higher-level question: Why is it necessary to make
> the OSGi system bundle appear as a JPMS module in the first place?
> 
> The scheme I previously suggested [2] maps an OSGi bundle wiring to a
> JPMS module and layer so that layers of JPMS modules can be resolved
> against the bundle directly.  If a particular bundle will never be used
> by a JPMS module, however, then there's no need to handle its wirings in
> that way, since there's no reason it needs to appear to be a JPMS 
module.
> 
> In a mixed OSGi/JPMS system would we realistically expect a JPMS module
> to require the OSGi system bundle, masquerading as a JPMS module, and 
use
> its exported APIs?  That seems pretty unlikely.  If a component uses an
> OSGi-specific API then shouldn't it just be written as an actual OSGi
> bundle in the first place?
> 
> Could your proof-of-concept implementation be made to work without
> putting the system bundle in a JPMS layer?  If so then it could continue
> to implement dynamic framework extensions just as it does today, support
> the dependence of JPMS modules upon OSGi bundles that export APIs that
> aren't specific to OSGi, and yet still not require the exposure of the
> low-level internal methods proposed by #LayerPrimitives.

No that cannot work without hacks to allow other modules to depend on the 
unnamed system.bundle module.  The reason is because we have bundles today 
that make extensive use of org.osgi.framework packages.  These bundles 
then also export packages that we want to make available to JPMS modules 
on top.  These bundles have to be loaded in to a named module in order to 
allow these JPMS modules to require them.  I think it would be an 
unfortunate work around to have to link an edge to an unnamed 
system.bundle module from a bundle module in order to get this 
functionality to work.  It also implies that it will be more difficult in 
the future to ship an osgi framework implementation jar as a real module 
since we must load the implementation of the framework into an unnamed 
module to be fully functional with respect to framework extensions.


FYI, for the most part I see your points about other solutions are 
possible to solve the performance issue with private packages.  I'm just 
pointing out that it was not a necessary concern before Java 9, so we need 
to be prepared to react.  The private-package scanning issue may well have 
to be solved outside of JPMS.  Particularly if the internals of addPackage 
consider the method to be rarely called (if ever) and therefore there is 
no need for it to be super fast.  But for supporting system.bundle 
fragment attachment the addPackage and addExportToAll methods are needed. 
The number of calls to these methods to support system.bundle fragments 
should be small and not as concerned with how speedy they are.  On the 
other hand, if addPackage is used to solve the private package scanning 
issue then addPackage must be exceptionally fast and thread safe.

Early on in my POC I had the idea of allowing the Layer creation to be 
able to map a class loader to a to a default module name.  Basically the 
reverse of the existing clf function.  Instead of mapping a module name to 
a class loader this would map a class loader to a default module name. Any 
package that gets defined in a package that is unknown to the modules 
associated with that class loader would get defined as part of the default 
module instead of the current unnamed module.  Would this be an acceptable 
solution for addPackage?  We still would need the addExportToAll though.

Tom

> 
> - Mark
> 
> 
> [1] http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html#jigsaw-2.3
> [2] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-
> October/000410.html
>