#LayerPrimitives aka allowing to add private package at runtime to a module ?

[Thomas Watson]

> 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.
> 
> Rémi

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.

Tom