Dynamic modules and bidirectional interoperation

[David M. Lloyd]

On 10/06/2016 02:20 PM, Thomas Watson wrote:
>
>
>> 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.

I see; but, doesn't that defeat the security benefits of the JPMS?  If 
the classes defined by the bundles themselves are outside of modules 
(i.e. in a class loader's unnamed module) then they are globally 
accessible via reflection/setAccessible.  If the security requirements 
are worthwhile, and we've all been proceeding on the assumption that 
they are, then it seems to me that this will ensure the obsolescence of 
OSGi (not to mention our deployment models).

This is the crux of many of our issues: if you accept that the JPMS 
security measures are worthwhile, then we either have a situation where 
the user has to choose between security or flexibility, or else we have 
to sacrifice flexibility to get the added security across the board, 
losing features in the process.  I continue to maintain that this is a 
false choice.

-- 
- DML