Dynamic modules and bidirectional interoperation
Thomas Watson
tjwatson at us.ibm.com
Thu Oct 6 20:17:41 UTC 2016
"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
More information about the jpms-spec-observers
mailing list