#LayerPrimitives aka allowing to add private package at runtime to a module ?
tjwatson at us.ibm.com
Thu Mar 16 13:55:01 UTC 2017
Sorry for the double email, I sent the first message to the observers list
> From: Remi Forax <forax at univ-mlv.fr>
> Aside, there is something that make me uncomfortable in the mails
> from David or Thomas, I'm maybe wrong, but it seems to me that you
> are thinking that you will be able to propose to your users to use
> the JPMS runtime with the current existing modules.
I'm not sure what you mean by existing modules here. I assume you mean
the existing modules from our own module systems (aka OSGi bundes).
> I think your are
> chasing an unicorn/trying to solve a problem nobody care, i maintain
> several OSGI bundles and i do not want an implementation of OSGI to
> see them as JPMS modules, not by default because they will not work,
> the encapsulation model of JPMS is far stricter than the current
> model (i think it's the same issue with JBoss Module but i've no
> experience with them).
I'm not proposing users of OSGi today will want to have their bundles
loaded as JPMS modules by default. I have a very specific usecase in mind
that does not apply to the scenarios OSGi is used for today because JPMS
does not exist yet.
We have a JEE runtime that is built out of OSGi bundles. If I am correct
JBoss is similar but built out of JBoss modules. Today we can deploy JEE
applications and control the access to APIs exported by our runtime from
the application class loader. Our APIs are loaded out of OSGi bundles.
The typical applications are not OSGi bundles. They are EARs, WARs, EJBs
etc. Now I am assuming at some point JEE will be updated to consider
delivering applications as JPMS modules, or perhaps something outside of
the JEE spec will become popular and it will be developed as JPMS modules
and we will want to support that. Here I assume the developers of these
application JPMS modules will want their modules loaded as real JPMS
modules. As such they will likely require standard named modules which we
provide today as OSGi bundles (e.g. java.servlet).
> As a user, if i create an OSGI module with a
> module-info or a bundle manifest that let me specified that this is
> a JPMS module, then i want it to be seen as a JPMS module but not by
> default. We have introduced a modulepath which is not a replacement
> of the classpath exactly for the same reason. So the interropt
> between OSGI and JPMS or JBoss Module and JPMS should be seen in my
> opinion with that idea in mind. In that case, supporting fragment
> that have also a JPMS module can be seen as a corner case, having to
> iterate over private packages is also not an issue because the
> existing manifest and the manifest of a JPMS module can be
> different, having more info, so at runtime the private packages will
> be available.
Private packages - I've already agreed that scanning for private packages
likely is something that should be solved outside of JPMS. Using a
dynamic addPackage to do this lazily probably is not the right solution.
You are correct, JPMS has some more strict rules.
- In JPMS a module is not open by default - In OSGi a bundle is always
open (perhaps in the future there will be a way to close a bundle)
- In JPMS no cycles are allowed - In OSGi cycles are allowed
- In JPMS no split packages are allowed - In OSGi split packages are
allowed (albeit not as a best practice)
But JPMS also does allow for a module to be mutable in certain ways.
- read edges are dynamic
- service uses are dynamic
- adding targeted open packages are dynamic
- adding targeted export packages are dynamic
All of which I assume can invalidate the cache you referred to. I use
this dynamic nature of modules to wire OSGi modules when the OSGi modules
break the strict rules you mention. But if there are no cycles or split
packages we are able to create an accurate Layer/Module hierarchy to
represent the bundles as open modules.
In our case the runtime has very few, if any, cycles and absolutely has no
split packages so I anticipate our bundles will accurately map into proper
module descriptions. With this in mind you may ask why we do not migrate
directly over to JPMS modules and run like any other JPMS module would. We
depend heavily on the most important parts of OSGi, which is not the
actual module system and class loading, instead it is the activation
lifecycle, service registry and configuration. It will be a massive
undertaking to migrate such things over to JPMS directly. But if you are
developing OSGi bundles that simply Export-Package, Import-Package and
Require-Bundle and do not participate in the rest of what OSGi offers for
component style development then JPMS is a perfectly suitable alternative.
With that said, I do not anticipate many will care to run their existing
OSGi applications as JPMS modules like we will want to if we have to
support applications built out of JPMS modules in the future.
More information about the jpms-spec-experts