Article on JPMS integration with existing module systems

[Thomas Watson]

From: mark.reinhold at oracle.com
> 2016/9/7 6:57:55 -0700, tim_ellison at uk.ibm.com:
> >>    1. Allow for code that manages a JPMS layer to have more control 
for 
> >> establishing read access for the modules contained in the managed 
layer. 
> >> The Module addReads method allows for read access to be added fora 
module 
> >> dynamically at runtime.  But it has a restriction that it must be 
called 
> >> by a class defined by the module that wants new read access.  It 
would be 
> >> a great help if we could call addReads from the management code that 
> >> created the layer.  Perhaps an addReads(Module wantsRead, Module 
toTarget) 
> >> method on Layer that checks the caller module is the same module get 
> >> created the Layer?  This could be used to solve a large set of issues 

> >> outlined above:
> > 
> > That sounds like a reasonable request.
> 
> This has come up in past discussions.  I don't think an API for this is
> strictly necessary.  Code that manages a layer presumably controls the
> class loaders in that layer, and hence already has the power to load
> arbitrary classes.  It can use that power to load tiny synthetic classes
> to add additional read edges as required, as Tom realized in his first
> experiment.  That's all a bit clunky, however, and we could make it
> easier, so for the record I'll enter a new issue:
> 
>   #ReadabilityAddedByLayerCreator -- Provide a means by which the code
>   that creates a layer can add readability edges from the modules in 
that
>   layer to other modules, whether those modules are in that layer or in
>   other layers.

In my view injecting code into a module in order to give the appearance 
that the call is coming from the module itself is pretty ugly so a 
solution to this issue would be very helpful for my scenario.  Not only 
would the code have to be injected into the module but I think the package 
the injected code is in would have to be 'exposed' for reflective reasons, 
during my prototype that meant I had to export the package in the 
ModuleDescriptor because there was no notion of 'weak' module or 'private' 
exports at the time.  That then causes issues for any JPMS layers on top 
because it would not allow modules in these layers to wire to more than 
one OSGi module because of split package restrictions.  To get around that 
we would have to generate a unique package to hold the code which is 
injected into each module.  Perhaps that would be less ugly depending on 
the outcome of #ReflectiveAccessToNonExportedTypes.  Exposing packages for 
reflective reasons should not mean the package is also available for 
classloading/linking like a normal package export in JPMS.

> 
> > ...
> > 
> >>    2. Allow for reflection on classes from concealed packages.  Many 
> >> dependency injection containers depend on being able to act upon 
concealed 
> >> classes in order to construct objects and inject the objects with 
> >> dependencies.  Forcing implementation details to be exported so that 
these 
> >> classes can be acted upon by DI containers is wrong.
> > 
> > I believe this is already covered by 
#ReflectiveAccessToNonExportedTypes
> > http://openjdk.java.net/projects/jigsaw/spec/issues/
> #ReflectiveAccessToNonExportedTypes
> 
> Yes, I think that's right.

I agree.

> 
> > ...
> >
> >>    3. Allow for sub-graphs of modules to be discarded within a layer.
> > 
> > Again, this sounds like a reasonable request.
> > 
> >>        - JPMS-ISSUE-007 - This would allow us to flush out the "dead" 

> >> modules which should never be used anymore.
> 
> This is a narrower form of the existing #MutableConfigurations issue 
[2].
> It could be easier to implement, however, so I'll enter it separately as
> 
>   #DiscardableModules -- Provide a means by which a sub-graph of modules
>   within a layer can be discarded, so that both those modules and their
>   class loaders can be reclaimed.

Thanks, although your follow on proposal may make this unnecessary.

> 
> >>    4. Allow a layer to map a class loader to a default named module. 
Any 
> >> classes from unknown packages to the JPMS would be assigned this 
named 
> >> module instead of the unnamed module.
> >> 
> >>        - JPMS-ISSUE-002 - This would allow us to avoid having to scan 
for 
> >> private packages.  Instead we would map the bundle classloader toa 
module 
> >> and that module could be used for the private packages.
> 
> Rather than introduce a notion of default named modules, I wonder if 
this
> problem could instead be addressed by tooling.  In JPMS we avoid 
scanning
> a modular JAR file for concealed packages by having the `jar` tool add a
> list of all the module's packages to the module descriptor as the JAR
> file is created.  This list is optional, so if it's missing we do scan
> the JAR file, but we expect that to be a rare occurrence.
> 
> If I understand the documentation correctly, bndtools does something
> similar by adding a `Private-Package` manifest header to record the list
> of non-exported packages in a bundle [3].  Could your OSGi-to-JPMS
> adaptation use that manifest header, when available, to avoid scanning
> for private packages?

Yes, this was going to be my approach for bundles built by bnd.  To be 
honest this item is #4 on my list of importance and approaches the 
category of "nice to have".  Even for the bundles where we have to scan 
for all packages the framework can easily cache the private-package 
information so that upon restart the scan is not needed again.

> 
> >>    5. Allow the JPMS requires statement to specify a module version.
> > 
> > Consideration of versioning was explicitly excluded from the original
> > requirements, and I don't see it coming in at this stage.  If you are
> > controlling the resolution of modules then you would be able to take 
account
> > of version numbers in the integration.
> 
> Right.  If you create your own ModuleFinder then you can arrange for the
> preferred version of each module to appear ahead of any other versions.
> 
> >>        - JPMS-ISSUE-006 - This would allow us to represent multiple 
> >> versions of a bundle within the bundle layer and give JPMS modules 
the 
> >> ability to specify which version they want.
> 
> I think the first part of this, i.e., representing multiple versions of 
a
> bundle within a single layer, can be avoided entirely, as I'll describe
> in a separate message.

I agree at this point, but have to think over your separate proposal in 
more detail.

Tom