Artical on JPMS integration with existing module systems

[Tim Ellison]

Obviously Tom has come at this integration challenge from his deep
knowledge of a particular OSGi implementation.  There are some
important observations, and minor tweaks to the current model that
will improve JPMS.

"Thomas Watson" <tjwatson at us.ibm.com> wrote on 18/08/2016 14:45:06:
> Below is the plain text format from an article I wrote on using JPMS 
> layers with an existing module system (OSGi).  Please excuse the poor 
> formatting.  I tried to make it is pretty as I could in plain text to 
> allow Mailman to let it through.  I have omitted the diagrams to avoid 
> this message getting held up by Mailman also.  If the diagrams are 
> important I can post them some other way later:

Disclosure: I read the html version, and trust that this plain text is a
faithful reproduction.

I'm going to snip out most of the original post too, which of course is
required reading to get the context and details for this experiment.
However, I want to focus on the specific recommendations for this group,
so I will skip straight to the conclusions.

<snip/> 

> Conclusion

Ok, this is where there are a few issues and recommendations that this
group can debate...

> This approach allows for a pretty accurate representation of a static 
set 
> of resolved OSGi bundles as JPMS modules.  But we are left with several 
> issues that need to be addressed before this can be considered a truly 
> viable solution.  Some may decide these are permanent restrictions of 
JPMS 
> that we will have to live with going forward.  But I believe there are 
> some tweaks to JPMS that could go a long ways to making this approach 
> close to a complete solution.  Listed below are some changes that would 
> help.  I listed them in the order of importance, but I think 1 and 2 are 
a 
> close tie for most important.
> 
>     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 for a 
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.

>         - JPMS-ISSUE-003 - We could avoid having to make JPMS aware of 
the 
> OSGI dependencies if we would be allowed to establish the read access 
> ourselves when the bundle layer is created.
> 
>         - JPMS-ISSUE-004 - If we avoid having to make JPMS aware of the 
> OSGi dependencies then we no longer have worry about restricting cycles.
> 
>         - JPMS-ISSUE-005 - If we can dynamically add reads then we can 
> enable dynamic package import to work by dynamically adding read access 
to 
> the provider of the package at runtime.
> 
>         - JPMS-ISSUE-008 - If we avoid having to make JPMS aware of the 
> OSGi dependencies then we no longer have to worry about restricting 
split 
> packages.
> 
>     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

>         - JPMS-ISSUE-001 - We would no longer have to declare the bundle 

> private packages as exported by the JPMS module.  Instead they can 
remain 
> concealed as they should be.
> 
>     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.
> 
>     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 to a 
module 
> and that module could be used for the private packages.
> 
>     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.

>         - 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.
> 
> My hope is that this experiment is useful in providing constructive 
> feedback to the JPMS expert group.  I hope they consider enhancing JPMS 
to 
> make JPMS layers more usable with existing module systems like OSGi.

Most of the suggestions are modest enhancements to the current model, so 
it
is encouraging to see that a good level of interoperability can be 
obtained
with a few minor tweaks.

Thanks for doing this experiment Tom.  I look forward to others' comments 
too.

> This was extracted from my article at: 
> http://blog.osgi.org/2016/08/osgi-with-java-modules-all-way-down.html

Regards,
Tim



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU