Dynamic modules and bidirectional interoperation
Thomas Watson
tjwatson at us.ibm.com
Thu Oct 6 19:20:17 UTC 2016
> From: "David M. Lloyd" <david.lloyd at redhat.com>
> > On 10/06/2016 01:36 PM, mark.reinhold at oracle.com wrote:
> > 2016/10/6 10:17:46 -0700, david.lloyd at redhat.com:
> >> A quick question...
> >>
> >> On 10/06/2016 12:07 PM, mark.reinhold at oracle.com wrote:
> >>> ... 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.
> >>
> >> Do read edges added at run time affect the subsequent linkage of
classes
> >> in the affected module?
> >
> > Read edges added at run time only affect run-time access-control
> > checks. They do not change the configuration previously computed
> > for the relevant layer. Subsequent configurations resolved against
> > that configuration will not take the new read edge into account.
>
> Then I do not believe that adding read edges alone will be sufficient as
> a resolution to #CyclicDependencies for either OSGi or our use cases,
> unfortunately, or at least I don't see how it could be.
> --
> - DML
>
My understanding is that read edges are needed to get past the
accessibility checks that are done by JPMS when a class is loaded by a
class loader which is associated with a Module known to JPMS itself. In
my experiment I attempted to represent the OSGi class loaders (wirings)
with a generated module which lives inside a bundle JMPS Layer. Once I
did this all the accessibility rules (for execution not class loading) are
enabled at the JPMS layer according to the read edges known by JPMS. But
the class loader delegation is still completely under the control of the
OSGi module system (framework). The read edges are needed so we can
represent the possible cycles, and even access to split packages from the
OSGi resolution graph between the Modules within the bundle layer(s). In
my experiment I chose to not express any dependencies in the
ModuleDesciptors which represent the OSGi bundles. Instead I create the
Layer holding the Modules and then after the Layer is "resolved" from JPMS
point of view I do addReads to wire the modules up according to the
delegation rules of OSGi resolution. This way I can get passed the cycle
and split package restrictions that are in place during JPMS Layer
resolution.
Tom.
More information about the jpms-spec-observers
mailing list