Dynamic modules and bidirectional interoperation

[Thomas Watson]

"David M. Lloyd" <david.lloyd at redhat.com> wrote on 10/06/2016 02:30:54 PM:
> >
> > 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.

I am not trying to define classes using the unnamed module.  My prototype 
was about trying to get out of the unnamed module space for the classes 
defined by OSGi class loaders.  Instead I am mapping an OSGi class loader 
to a real module that I generated within a JPMS Layer API, by using the 
custom class loader mapping features of JPMS.  The read edges are needed 
to continue to grant the runtime accessibility needed for the packages 
exported by the Module in the OSGi Layer to properly mimic the delegation 
rules OSGi resolves in the framework.  This does not open up deep 
reflection by or to the classes defined by OSGi class loaders.  These 
classes still follow the rules of JMPS.  And that is where the issues 
outlined in the #ReflectiveAccessToNonExportedTypes thread pop up. Ideally 
the ModuleDescriptors representing OSGi bundles will only export the 
packages which the OSGi bundle manifest exports (using Export-Package). 
Depending on how the #ReflectiveAccessToNonExportedTypes works out we also 
would likely need to 'expose' all the private packages from OSGi bundles 
for deep reflection by default.  My assumption is that the 'exposed' 
packages are not available for class loader delegation, only for 
reflection.  That is if we want to maintain the behavior of OSGi today 
which allows deep reflection on any types private or public, exported or 
not.

> 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).

I don't disagree.  I would hope that JPMS Layer creation is flexible 
enough to allow our existing module systems to be represented in a custom 
Layer of sorts and maintain a high level of functionality which we enjoy 
today on Java 8.

> 
> 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.

I don't disagree, but if we have a good outcome to 
#ReflectiveAccessToNonExportedTypes which allows us to 'expose' packages 
for deep reflection then we can at least maintain functionality of our 
existing module systems in a JPMS Layer world.  Perhaps over time the 
existing module systems will be enhanced such that deep reflection is not 
needed as much or at least not assumed available by default.  But such a 
change to existing module systems to restrict such things is going to be 
just as disruptive as the #ReflectiveAccessToNonExportedTypes issue is for 
JPMS, so that will not come quickly in my opinion.

Tom