Artical on JPMS integration with existing module systems
Tim Ellison
Tim_Ellison at uk.ibm.com
Wed Sep 7 13:57:55 UTC 2016
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
More information about the jpms-spec-comments
mailing list