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