Dynamic modules and bidirectional interoperation

[Thomas Watson]

Overall I think this approach with #NonHierarchicalLayers is worth 
pursuing.  A couple of observations.

1) Any OSGi dependencies that influence class loader delegation will not 
be declared in the ModuleDescriptors which represent the OSGi bundle 
wirings.  Instead we will depend on the ability to 
#ReadabilityAddedByLayerCreator to wire up the modules within the bundle 
Layer according to OSGi resolution rules.  It has a drawback if there are 
cases where some system code is trying to reason about modular 
dependencies by using the JPMS module API.  I think this will have to be 
acceptable because I don't think we will be able to fully converge on all 
the possible dependency types available in the existing module systems. 
For example, OSGi has Require-Bundle which maps closing to JPMS requires, 
but OSGi also has Import-Package dependencies which cannot be mapped 
properly into JMPS module Layers.

2) I assume #NonHierarchicalLayers will be restricted to form a directed 
acyclic graph.  As such I assume each node in the graph of Layers would be 
visited only once when resolving new Layers on top even if there are 
multiple paths to the layer from the new Layer being resolved.

Tom



"jpms-spec-observers" <jpms-spec-observers-bounces at openjdk.java.net> wrote 
on 10/06/2016 12:07:59 PM:

> From: mark.reinhold at oracle.com
> 
> Here, then, is an alternative approach:
> 
>   - Map each bundle wiring to a unique JPMS module, configured and
>     instantiated in its own unique bundle-wiring layer.  An OSGi bundle
>     will then be associated not only with a sequence of bundle wirings
>     over time, but also with a sequence of JPMS module descriptors,
>     configurations, modules, and layers over time.  A layer can be
>     reclaimed after no strongly-reachable layers refer to it, so
>     discarded bundle-wiring layers -- and their class loaders -- won't
>     be retained unnecessarily.  There's no need to represent multiple
>     versions of the same bundle within a single layer, since every
>     bundle wiring has its own layer (part of JPMS-ISSUE-006 in [3]).
> 
>   - Extend JPMS with #NonHierarchicalLayers, so that a set of JPMS
>     modules can be resolved against modules in more than one parent
>     layer.  An ordinary JPMS layer can then have multiple bundle-wiring
>     layers and ordinary JPMS layers as parents.
> 
> To illustrate, here's a diagram that elaborates upon the second diagram
> in Watson's note:
> 
>     http://cr.openjdk.java.net/~mr/jigsaw/notes/osgi-on-jpms.png
> 
> The left-hand side shows a layer containing two ordinary JPMS modules,
> jpms.a and jpms.b, resolved against two OSGi bundle-wiring layers, for
> bundle.a and bundle.b.  (The blue boxes represent JPMS modules; the
> orange boxes are the class loaders created by the OSGi framework.)  The
> right-hand side depicts some later time after which bundle.b has been
> updated, so its original JPMS module and layer were discarded and a new
> module and layer were created for it (bundle.b layer 2).  The JPMS 
module
> layer had the original bundle.b layer as one of its parents so it, too,
> was discarded and a new JPMS layer was created with the second bundle.b
> layer -- along with the original, unchanged bundle.a layer -- as its
> parents.
> 
> This implementation of OSGi bundles in terms of JPMS modules leverages
> the fact that OSGi already associates a bundle with a sequence of bundle
> wirings over time, and each new bundle wiring has its own unique class
> loader.  All we are doing here is wrapping each of these class loaders 
in
> its own module and layer, so that ordinary JPMS modules can be 
configured
> to refer to them.  There could be many such layers but these layers are
> very lightweight, since their sole function is to associate a single
> module with an existing class loader for the purpose of access control.
> This approach should generalize to other module systems that support
> dynamic modules in a similar fashion, i.e., by creating a new class
> loader each time a dynamic module is updated.
> 
> There are, no doubt, further details to work out, such as exactly how to
> synthesize the module descriptors for bundle wirings so that they can
> sensibly be referenced by ordinary JPMS modules.  Cyclic relationships
> amongst OSGi bundles and split packages across bundles can't be modeled
> directly in module descriptors, but I suspect they can be accommodated 
by
> inserting the necessary additional readability edges after the relevant
> layers are instantiated.  Overall this does, however, appear to be a
> promising approach to supporting dynamic modules and bidirectional
> interoperation without adding undue complexity to the platform module
> system itself.
> 
> To enable this with the present design we do need 
#NonHierarchicalLayers;
> that's a significant change, but I think it's feasible and will explore
> it further.  In order to model the cyclic graphs and split packages that
> are possible in other module systems it'd be convenient, but not 
strictly
> necessary, to have #ReadabilityAddedByLayerCreator [5].  We have no need
> for #MutableConfigurations, #LazyConfigurationAndInstantiation, or
> #DiscardableModules, which I think is a big win for simplicity.
> 
> Comments?
> 
> - Mark
> 
> 
> [1] 
http://openjdk.java.net/projects/jigsaw/spec/reqs/#dynamic-configuration
> [2] http://openjdk.java.net/projects/jigsaw/spec/reqs/#interoperation
> [3] http://mail.openjdk.java.net/pipermail/jpms-spec-comments/2016-
> August/000062.html,
>     or 
http://blog.osgi.org/2016/08/osgi-with-java-modules-all-way-down.html
> [4] 
http://openjdk.java.net/projects/jigsaw/spec/issues/#DiscardableModules
> [5] http://openjdk.java.net/projects/jigsaw/spec/issues/
> #ReadabilityAddedByLayerCreator
>